This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [RFC v3 05/23] sysdeps/timespec_get: Use clock_gettime64 if avaliable
* Arnd Bergmann:
> On Wed, Jul 17, 2019 at 7:08 AM Florian Weimer <fweimer@redhat.com> 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