Re: [PATCH v2 12/13] sparc64: vdso: Implement clock_getres()

["Arnd Bergmann" <arnd@arndb.de>]

On Mon, Aug 18, 2025, at 15:00, Thomas Weißschuh wrote:
> On Mon, Aug 18, 2025 at 08:54:53AM +0200, Arnd Bergmann wrote:
>> On Mon, Aug 18, 2025, at 07:50, Thomas Weißschuh wrote:
>> > On Fri, Aug 15, 2025 at 10:09:23PM +0200, Arnd Bergmann wrote:
>> 
>> The glibc code has a weird mixup of the time32 and time64
>> function names, but from what I can tell, it only ever sets
>> dl_vdso_clock_getres_time64 on 64-bit architectures, where it
>> gets set to the normal clock_getres vdso symbol. On 32-bit,
>> glibc always skips vdso_clock_getres_time64() since it
>> does not exist, and then it always calls clock_getres_time64()
>> through the syscall interface, unless it runs on pre-5.6
>> kernels that fall back to the time32 vdso or syscall.
>
> Ack.
>
> So with 'time64 userspace', you mean '32-bit, time64 userspace', correct?

Yes

>> Two related points:
>> 
>> - something we could add on all 32-bit architectures after
>>   everything uses the generic vdso implementation is
>>   vdso_gettimeofday_time64(), this can shave off a few cycles
>>   because it avoids a division that may be expensive on some
>>   architectures, making it marginally more useful than
>>   vdso_clock_getres_time64().
>
> You mean this division in __cvdso_gettimeofday_data()?
>
> 	tv->tv_usec = (u32)ts.tv_nsec / NSEC_PER_USEC;
>
> Switching the subseconds field to nanoseconds to avoid the division and the
> seconds field to 64bit to avoid overflows brings us back to
> 'struct __kernel_timespec' again, no? What would be the advantage of this over
> vdso_clock_gettime(CLOCK_REALTIME, &ts)?

I misremembered what the current code does. As you point out,
there is a division by NSEC_PER_USEC in the vdso as well, so
there is no difference between libc calling vdso_clock_gettime()
and vdso_gettimeofday() in the number of divisions.

If we wanted to optimize this bit, the division would need
to be folded into vdso_calc_ns()/mul_u64_u32_add_u64_shr(),
which is nontrivial.

>> - there is one catch on sparc64 in the way it defines
>>   __kernel_old_timeval with a 32-bit __kernel_suseconds_t,
>>   unlike all other 64-bit architectures. This is incompatible
>>   with glibc's __timeval64 definition on sparc32, so there
>>   would need to be a special case for sparc32 somewhere,
>>   either in the kernel or in glibc.
>
> This is only a problem together with vdso_gettimeofday() from above, right?

Correct. I took a look at your sparc64 gettimeofday() to make
sure it uses the correct types and that seems fine since it
gets the __kernel_old_timeval structure definition from the
the sparc64 uapi headers.

     Arnd