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.8 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 3C57E1F461 for ; Thu, 29 Aug 2019 17:49:30 +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:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-type; q=dns; s=default; b=rRMN 81VrxtsdIDJAu05rdxXZpm4pwoE7Z4mQkpIypfsz8xEBQeU9SEQxCqgxVObYuctu ksKHvu0BW8Nr7kiVj4M3Kho4ebLcZmOAY4gWNC8wVKHd4PLtnauG6MjUU91zHnEH xgQgI34RQ/VilzJaA8woFb389++SY6HAaxyai38= 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:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-type; s=default; bh=DQHNDLPTGa xzfdE/BW0JKAqv5K0=; b=wYwFnsVE+hbw3NbLTjltFoVMB5n0jCabH/LMHmW/8E AymQdn3UjGHMSpfh/c0JF8NOjOjMvu8iqMz1gdQFtaIih5LBQOP/pX7J6AcojdsD /o6gF9t1OEeuou2Tigl9sLeOK7pCIvJUgAavf6PuEcxM1ZxIXIuVEEpRsYMfLI3j M= Received: (qmail 41427 invoked by alias); 29 Aug 2019 17:49:27 -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 41419 invoked by uid 89); 29 Aug 2019 17:49:27 -0000 Authentication-Results: sourceware.org; auth=none X-HELO: mailbackend.panix.com MIME-Version: 1.0 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> In-Reply-To: <87imqh9dhm.fsf@oldenburg2.str.redhat.com> From: Zack Weinberg Date: Thu, 29 Aug 2019 13:49:12 -0400 Message-ID: Subject: Re: [PATCH v2 05/10] Use clock_gettime to implement time. To: Florian Weimer Cc: Paul Eggert , GNU C Library , Joseph Myers , Lukasz Majewski , Alistair Francis , Stepan Golosunov , Arnd Bergmann , Adhemerval Zanella , Samuel Thibault Content-Type: text/plain; charset="UTF-8" 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. 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). 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. zw