From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS3215 2.6.0.0/16 X-Spam-Status: No, score=-5.0 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,MAILING_LIST_MULTI,NICE_REPLY_A, RCVD_IN_DNSWL_HI,SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server2.sourceware.org [IPv6:2620:52:3:1:0:246e:9693:128c]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 15A841F8C6 for ; Mon, 12 Jul 2021 14:20:53 +0000 (UTC) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 5D9BF3835815 for ; Mon, 12 Jul 2021 14:20:51 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 5D9BF3835815 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1626099651; bh=v4YWQBVKpOD/y0ebeF32cqhxT/YIecU1tT7eNTcZr/w=; h=Subject:To:References:Date:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=CyXXADdBacffeg5ych9LHVU6YMaNNKtVdRcj+Trx+qOsp0jjpeSRzLU5/+HQgEZJn ukspxp7wWrKwN5AsqYwc376I+lG+GVx2M5sVf8EzXmqa8dTPsVYVA9F8owkQ9POe54 +oihK5dy7iZpvEiPMAJRQ/Gktsvagy69NfMAoIwc= Received: from mail-pf1-x42a.google.com (mail-pf1-x42a.google.com [IPv6:2607:f8b0:4864:20::42a]) by sourceware.org (Postfix) with ESMTPS id C6107383D01B for ; Mon, 12 Jul 2021 14:20:30 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org C6107383D01B Received: by mail-pf1-x42a.google.com with SMTP id j9so10858682pfc.5 for ; Mon, 12 Jul 2021 07:20:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=v4YWQBVKpOD/y0ebeF32cqhxT/YIecU1tT7eNTcZr/w=; b=uMGA50roMqlGQ/pHnVkuKatrjP0xwT3MBxOAlQ+BF+byecQsoVKjb8/XXa3spz5uZQ Wj6foFUYCpEVL/g8HP1P75j+hjSBySe2wq5OcutGKLzl/3+MKrd+UZzJWo9f9K4VVIMc 0OemOhDjocNcYtDPQD3SOW45Y289SCIq+Oun/le7aBqxnKBRzAYRXCE4JgPoTVajlfKo QWw5WvIcJUHTBbRxSDj4ze+k9plrMnSwZP8omQmVuMmwwOhRdHT9tX+mXfhE6ucpN/rg flEA/1OA0EXmxqsmXPAemFv/ZXCRyOljzbhVykFtaOQ2G3oGHvOZKJxuSLobBHEMaAiT Ac7A== X-Gm-Message-State: AOAM531Ycrd0xltBfj6o6H10jXGzC4DOVR9dkILohq7N6tjy8j5+IQeM u35slkbgSXkJyEG44xLAUW58ViPj/83uCA== X-Google-Smtp-Source: ABdhPJwXzaeXgEzOY9DKi6QckDWhouk4/K7qWkUuzQ8Jtg7i/gINnIij2luA6QuKqlFd/jGOzvwrGA== X-Received: by 2002:aa7:8b56:0:b029:2b9:77be:d305 with SMTP id i22-20020aa78b560000b02902b977bed305mr53655580pfd.61.1626099629671; Mon, 12 Jul 2021 07:20:29 -0700 (PDT) Received: from [192.168.1.108] ([177.194.59.218]) by smtp.gmail.com with ESMTPSA id b18sm9896347pji.39.2021.07.12.07.20.28 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 12 Jul 2021 07:20:29 -0700 (PDT) Subject: Re: [PATCH] Linux: Use 32-bit vDSO for clock_gettime, gettimeofday, time (bug 28071) To: Florian Weimer References: <87czrqf5un.fsf@oldenburg.str.redhat.com> <878s2ef19p.fsf@oldenburg.str.redhat.com> <874kd2ey6s.fsf@oldenburg.str.redhat.com> <158cdbcb-5335-9ff4-cf3e-a45d8603d029@linaro.org> <878s2bdddm.fsf@oldenburg.str.redhat.com> <87zgurad11.fsf@oldenburg.str.redhat.com> Message-ID: <03207aa6-6bf3-febe-2b7f-30174faede60@linaro.org> Date: Mon, 12 Jul 2021 11:20:26 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <87zgurad11.fsf@oldenburg.str.redhat.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Adhemerval Zanella via Libc-alpha Reply-To: Adhemerval Zanella Cc: libc-alpha@sourceware.org Errors-To: libc-alpha-bounces+e=80x24.org@sourceware.org Sender: "Libc-alpha" On 12/07/2021 10:15, Florian Weimer wrote: > * Adhemerval Zanella: > >> On 12/07/2021 07:40, Florian Weimer wrote: >>> * Adhemerval Zanella: >>> >>>> Using the test (a slight modified one from the bug report): >>>> >>>> -- >>>> #include >>>> #include >>>> #include >>>> >>>> int >>>> main (void) >>>> { >>>> struct timespec ts; >>>> errno = 0; >>>> clock_gettime (CLOCK_REALTIME, &ts); >>>> printf ("errno = %m (%d)\n", errno); >>>> errno = 0; >>>> clock_gettime (CLOCK_MONOTONIC, &ts); >>>> printf ("errno = %m (%d)\n", errno); >>>> } >>>> -- >>>> >>>> I see no syscall on 5.11 kernel, only a clock_gettime (CLOCK_MONOTONIC) >>>> on the 4.4 and a clock_gettime_time64 plus a clock_gettime on the 3.10. >>> >>> This still introduces a severe performance regression on older kernels. >>> It may well make some exsting 32-bit applications unusable until the >>> kernel is upgraded. I'm not sure if this is a good idea. >>> >>> At least I can see that the clobbering of errno is gone. >> >> Yes and this how we initially decided to provide 64-bit time_t support, >> where 32-bit implementations are done on top of 64-bit ones. I am not >> very fond of starting to adding 32-bit specific implementations, the >> complexity to fix some specific cases do not really pay in the long >> term imho. >> >> We might also add back the global time64 internal variable that indicates >> if the kernel supports 64-bit (removed by 9465c3a9fb557), but it also has >> its ow issues (live migration like CRIU). > > Hmm. I see. Let's fix the ENOSYS issue then because it breaks OpenJDK. > > I'm a bit surprised that we still see the extra syscalls with your > patch, but I suppose that's just the way the INTERNAL_VSYSCALL_CALL > macro works. The INTERNAL_VSYSCALL_CALL issues the syscall if the vDSO is not present as a fallback mechanism. It should not be really necessary on most implementation currently, but there are some architectures and kernel version where the vDSO does not actually does it (I think mips on kernel 4.x version). However, I think open-coding is should be simple; specially now for the case we do not really want it to fallback to syscall. > > Regarding the actual patch, there are a few missing spaces before > parenthesis: > > + int (*vdso_time64)(clockid_t clock_id, struct __timespec64 *tp) > + = GLRO(dl_vdso_clock_gettime64); > + int (*vdso_time)(clockid_t clock_id, struct timespec *tp) > + = GLRO(dl_vdso_clock_gettime); My understanding is for GLRO the space is not really required because the macro is not used a function call. I followed the same idea for the function pointer definition. Regardless of the missing space, are you ok with my patch then? > > Thanks, > Florian >