[PATCH v2 05/10] Use clock_gettime to implement time.

[Florian Weimer]

* Zack Weinberg:

> On Wed, Aug 28, 2019 at 5:39 PM Florian Weimer <fweimer@redhat.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
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.

Thanks,
Florian