Re: [PATCH v2 2/7] y2038: Introduce __ASSUME_64BIT_TIME define

[Arnd Bergmann <arnd at arndb dot de>]

On Wed, May 15, 2019 at 5:39 PM Lukasz Majewski <lukma@denx.de> wrote:
> > On Wed, 8 May 2019, Lukasz Majewski wrote:
> > If it is, with the same symbol version as
> > used for existing vDSO symbols, or a different symbol version?  If
> > not in the vDSO, are there any performance implications from using a
> > clock_gettime64 syscall in place of a clock_gettime call to the vDSO?
> >
>
> This would need to be checked how severe is the performance regression
> when one uses clock_gettime64 instead of dedicated __vdso_clock_gettime
> (aliased to clock_gettime()).
>
> It is also up to the Linux kernel community to decide if it is
> acceptable to introduce vclock_gettime64.c file, which would provide
> vdso for clock_gettime64.

The vdso code is undergoing a rewrite to use the same implementation
across all architectures, once that is complete, the added clock_gettime64
vdso support is added trivially.

We decided not to add the calls earlier since that would clash with the
rewrite, and not be easily testable across architectures.

> > (I think the code using the vDSO will automatically fall back to a
> > corresponding syscall if the vDSO symbol isn't there, but answers to
> > those questions will still be relevant for reviewing any patch for
> > clock_gettime64 and understanding exactly what code paths it will
> > use.)
>
> Yes, correct as in [1], [2].
>
> However, I do believe that on the beginning glibc shall support only
> the syscall version of clock_gettime64 and make the switch for vdso
> only when it is available from the Kernel.

I think you need to do that anyway, since not all 32-bit architectures
support a vdso at all. As I understood, all vdso support is optional,
so there is always a runtime fallback to deal with kernels lack
the vdso for some reason.

       Arnd