Re: [RFC v3 05/23] sysdeps/timespec_get: Use clock_gettime64 if avaliable

[Arnd Bergmann <arnd at arndb dot de>]

On Wed, Jul 17, 2019 at 10:12 AM Florian Weimer <fweimer@redhat.com> wrote:
> * Arnd Bergmann:
> > On Wed, Jul 17, 2019 at 7:08 AM Florian Weimer <fweimer@redhat.com> wrote:
> >> * Alistair Francis:
> > 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.

I understand that it would be much slower on that particular combination,
I just can't think of anyone who would run into this in practice outside of
validation testing that makes sure glibc does run this way.

If you have any real-world binary built with 64-bit time_t, this will
require all library dependencies other than glibc to be built the same way
and that in turn won't happen unless someone builds a whole distro
for 64-bit time_t, which would be crazy unless they also use a modern
kernel.

I can understand the need to make it work in principle, but does it
have to be efficient?

      Arnd