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

[Lukasz Majewski <lukma at denx dot de>]

Hi Arnd,

> 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.

Thanks for sharing the update.

> 
> > > (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.

Yes, correct - there is always a fallback when vsdo is not available.

> 
>        Arnd




Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lukma@denx.de

Attachment: pgp7DZM3oSupU.pgp
Description: OpenPGP digital signature