This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH v2 05/10] Use clock_gettime to implement time.
- From: Florian Weimer <fweimer at redhat dot com>
- To: Zack Weinberg <zackw at panix dot com>
- Cc: Paul Eggert <eggert at cs dot ucla dot edu>, GNU C Library <libc-alpha at sourceware dot org>, Joseph Myers <joseph at codesourcery dot com>, Lukasz Majewski <lukma at denx dot de>, Alistair Francis <alistair23 at gmail dot com>, Stepan Golosunov <stepan at golosunov dot pp dot ru>, Arnd Bergmann <arnd at arndb dot de>, Adhemerval Zanella <adhemerval dot zanella at linaro dot org>, Samuel Thibault <samuel dot thibault at ens-lyon dot org>
- Date: Mon, 02 Sep 2019 15:32:33 +0200
- Subject: Re: [PATCH v2 05/10] Use clock_gettime to implement time.
- References: <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <CAKCAbMiqG75Pr51-OR8u+PxEQZ303qHgj2XZO0fZqJoYOsfjhg@mail.gmail.com>
* Zack Weinberg:
> On Wed, Aug 28, 2019 at 5:39 PM Florian Weimer <email@example.com> 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
> 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.
> 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
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.