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=-4.0 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 3ED481F461 for ; Wed, 17 Jul 2019 08:12:15 +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:from:to:cc:subject:references:date:in-reply-to :message-id:mime-version:content-type; q=dns; s=default; b=shBO4 KUC4KOigERuducSCX/Axwhq9gPZgALj0oi0phWg0SU1mwaOizFxS28hzgFa3akrJ Jv/G7/bdTjQ83PFNKW1TikNb55e8NzYdx7ygxt/b82ZUwZJlZ1HJAsC8hI+OXbv5 IK/fg356Dx8zQFubRX/bNqZpk50NSGZHSfRPGU= 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:from:to:cc:subject:references:date:in-reply-to :message-id:mime-version:content-type; s=default; bh=q/6eytVrn8p AQA9dRV4jKHSYhyA=; b=R1cC7WLT2+IIuogFZeh72J0YhRdmOKwLd9skIZVvz5S oQBDeC9EHGmsxlzuY+7e9uYF+L+5+A5Yehx0m2lPIXxmtspLZ5+5KyFhR0+BfrdB T6+v0k49/6M+OGokHVEDz96UKJFfFiyZNNf7HONl5lPbjCkhM+fgpMm7OQLP2VOY = Received: (qmail 58278 invoked by alias); 17 Jul 2019 08:12:13 -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 58232 invoked by uid 89); 17 Jul 2019 08:12:08 -0000 Authentication-Results: sourceware.org; auth=none X-HELO: mx1.redhat.com From: Florian Weimer To: Arnd Bergmann Cc: Alistair Francis , GNU C Library , Adhemerval Zanella , Palmer Dabbelt , macro@wdc.com, Zong Li , Alistair Francis Subject: Re: [RFC v3 05/23] sysdeps/timespec_get: Use clock_gettime64 if avaliable References: <0d116a8faab58db1952a256c6cb75e7b0f9af444.1563321715.git.alistair.francis@wdc.com> <87zhlddz8v.fsf@oldenburg2.str.redhat.com> Date: Wed, 17 Jul 2019 10:11:58 +0200 In-Reply-To: (Arnd Bergmann's message of "Wed, 17 Jul 2019 09:59:21 +0200") Message-ID: <878ssxcc6p.fsf@oldenburg2.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain * Arnd Bergmann: > On Wed, Jul 17, 2019 at 7:08 AM Florian Weimer wrote: >> >> * Alistair Francis: >> >> > +#if __WORDSIZE == 32 >> > +int >> > +__timespec_get (struct timespec *ts, int base) >> > +{ >> > + int ret; >> > + >> > +#ifdef __NR_clock_gettime64 >> > + struct __timespec64 ts64; >> > + ret = INTERNAL_VSYSCALL (clock_gettime64, err, 2, CLOCK_REALTIME, &ts64); >> > + >> > + ts->tv_sec = ts64.tv_sec; >> > + ts->tv_nsec = ts64.tv_nsec; >> > + >> > + if (! in_time_t_range (ts->tv_sec)) >> > + { >> > + __set_errno (EOVERFLOW); >> > + return -1; >> > + } >> > +#endif >> > + >> > +#ifndef __ASSUME_TIME64_SYSCALLS >> > + ret = INTERNAL_VSYSCALL (clock_gettime, err, 2, CLOCK_REALTIME, ts); >> > +#endif >> >> I don't think this is right. I think you need to cache clock_gettime64 >> support somewhere and avoid trying to call the non-existing system call >> again and again. > > How important is this? It sounds like a micro-optimization for a case that > very few people are going to hit, given that running an application with > 64-bit time_t on an old kernel will likely hit other bugs that glibc cannot > deal with. I don't think it's a microoptimization. On old kernels without clock_gettime64 in the vDSO, 32-bit timespec_get will always make the system call, which fails. Only then the 32-bit clock_gettime in the vDSO is used. This effectively negates the performance benefit of the vDSO, I think. (Not sure if this will even build on non-RV32 as posted, given that we don't have a vDSO variable in glibc for clock_gettime64, but I assume that's going to be fixed if necessary.) Thanks, Florian