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

[Adhemerval Zanella <adhemerval dot zanella at linaro dot org>]

On 02/09/2019 10:32, Florian Weimer wrote:
> * 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.

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