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: AS31976 209.132.180.0/23 X-Spam-Status: No, score=-3.9 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_EF,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 10B9E1F461 for ; Mon, 2 Sep 2019 18:35:48 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:to:cc:references:from:subject:message-id:date :mime-version:in-reply-to:content-type :content-transfer-encoding; q=dns; s=default; b=KHl1Dd5YUDTysjzF MpLs2caLLWw2GqDosOXh6MgZ3sx3NCt40K5rt3xb8RAtGbBWk6aOGALFt6LXhs9o E9UOJxZOiDnb+yyxii1h1uv2QT4kIY6bVc0LZwq5/WC/qREuVY845xCt6ixl5Olj B6YbJrGN/d0jyJ8XL+eHN0qDaPo= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:to:cc:references:from:subject:message-id:date :mime-version:in-reply-to:content-type :content-transfer-encoding; s=default; bh=it6/Z2PTxdIO+vDV27vyBN 35Wco=; b=YBI8amorRIS/FsTTwgxMKndftpQ+GLMRbhXrrKSoB6TGIzMP1rmzpm bWdh/gsDH+vKbD/EPw9F8x4Zgt8moWflyzLnq9dzngtbreZYQcMaIiEq6WHGse/T OIWvRCRoBmCAhceFlv8JIhCpRi0yHgERxEn3WMpei+/NEt84EoRmU= Received: (qmail 16928 invoked by alias); 2 Sep 2019 18:35:46 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 16920 invoked by uid 89); 2 Sep 2019 18:35:46 -0000 Authentication-Results: sourceware.org; auth=none X-HELO: mail-qk1-f194.google.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=to:cc:references:from:openpgp:autocrypt:subject:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=gSakzHw1kw+0IT6Afvjy/cQwZYbEf7UO6Ipf1XzN0gk=; b=WEJ6t2Yrw/syAxGIupiX5qbAD3jGs729wlfdYmpUNbqwwtmBPzmxTYfugK5u9TAWdL XvTzeqkklieIJBGf+Xizr3Hib1y811hPqNDVuMCKxV1cXqhPjsO8BtBmciMe1qXsNWBD jOrvZ0lVELR0gAjPZSTPs8j28GeRh/s9KC7QbK7h4uWkHaKaFBkyxlEspQ5gMbUbCC4O +ZBCUja04sHv2l+yQUkNr10/RHAtBcfrzNN4n+r1v0OLkR19Ztc/tpIi2Wm3mWURBlJV RvqOSNkhdvFHFOfp6dnj8GMXlCSWGArtZad0TqDRwfF5wTyak6P7F5ZnmOGgVBXBxoLE xhmQ== To: Florian Weimer , Zack Weinberg Cc: Paul Eggert , GNU C Library , Joseph Myers , Lukasz Majewski , Alistair Francis , Stepan Golosunov , Arnd Bergmann , Samuel Thibault References: <20190828153236.18229-1-zackw@panix.com> <20190828153236.18229-6-zackw@panix.com> <87muftb1fk.fsf@oldenburg2.str.redhat.com> <87sgpl9h2o.fsf@oldenburg2.str.redhat.com> <321d1bd0-a9f6-310b-5412-a023d813e90f@cs.ucla.edu> <87imqh9dhm.fsf@oldenburg2.str.redhat.com> <87r24yvn66.fsf@oldenburg2.str.redhat.com> From: Adhemerval Zanella Openpgp: preference=signencrypt Subject: Re: [PATCH v2 05/10] Use clock_gettime to implement time. Message-ID: <0bac22b8-e46e-5f4f-9818-1eb65acf2c59@linaro.org> Date: Mon, 2 Sep 2019 15:35:36 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <87r24yvn66.fsf@oldenburg2.str.redhat.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit On 02/09/2019 10:32, Florian Weimer wrote: > * Zack Weinberg: > >> On Wed, Aug 28, 2019 at 5:39 PM Florian Weimer wrote: >>> I think we should keep using the time entry in the vDSO. This >>> consolidation is just not possible to do for performance reasons. >> >> To be crystal clear about where I'm coming from, I think this >> consolidation is *necessary* to clear the way for the y2038 patches. > > But it's not an absolute technical requirement, right? > > I mean, if we wanted, we could still add a file like > sysdeps/unix/sysv/linux/x86_64/time.c and do things differently there? > (Although we'd also have to change the vDSO setup code for an efficient > implementation.) > >> And I was under the impression that the kernel people wanted to >> withdraw support for the time and gettimeofday entry points (at least >> for new architectures going forward). > > Yes, but that doesn't mean they want performance regressions on x86-64. > I think. > >> So I'm only looking for ways to mitigate the performance impact at >> this point. Before I back off on "henceforth we only call the >> kernel's clock_gettime" I would need to hear *both* a really >> compelling argument for why we need to keep calling the time or >> gettimeofday entry points -- a few ns more expense on a call that only >> reports the time to the nearest second isn't going to cut it -- *and* >> an explanation of why it won't interfere with the y2038 work and/or >> why we won't have to stop using them in the future anyway. > > I expect that people have time calls in (binary) logging code where this > is visible. I think EXPLAIN ANALYZE in PostgreSQL also rather sensitive > to timing performance, but fortunately it already uses > clock_gettimeofday. > > I'm not too concerned here (assuming that we *can* still optimize the > time function on select architectures if that proves necessary in a > couple of years). It's just that I really dislike the idea of > performance regressions on 64-bit architectures as a side effect of > Y2038 support on 32-bit architectures. I think the *default* implementation for time should indeed be done through clock_gettime, as this patch intends, however I also think it is possible to keep arch-specific code in place so the optimized vDSO implementation are used. It will also allow each arch maintainer to do the switch if the consensus would to use the default one. My view is we can use my proposed patch to refactor time [1], and change the fallback syscall path to call clock_gettime instead. I can work towards the modification. [1] https://sourceware.org/ml/libc-alpha/2019-07/msg00157.html