Re: [PATCH 1/2] vdso: sparc: stub out custom vdso implementation

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

On Thu, Jul 10, 2025, at 18:22, Andreas Larsson wrote:
> On 2025-07-07 18:05, John Paul Adrian Glaubitz wrote:
>> On Mon, 2025-07-07 at 17:45 +0200, Arnd Bergmann wrote:
>>> On Mon, Jul 7, 2025, at 17:22, John Paul Adrian Glaubitz wrote:
>>>>
>>>> On Mon, 2025-07-07 at 16:46 +0200, Arnd Bergmann wrote:
>>>>> Rip out the whole thing and replace it with a minimal stub as we do
>>>>> on parisc and uml. This introduces a small performance regression when
>>>>> using a libc that is aware of the vdso (glibc-2.29 or higher).
>>>>
>>>> Can this performance hit quantified in any way?
>>>
>>> It's trivial to test calling glibc clock_gettime() in a loop
>>> on a specific piece of hardware, the difference should largely
>>> depend on how long the timer hardware access takes compared
>>> to the syscall overhead.
>>>
>>> On machines that have neither TICK nor STICK clocksource, the
>>> simpler version should even be minimally faster, on those that
>>> have one of the two, there is an added cost for entering the
>>> syscall on every clock_gettime() as we do on architectures without
>>> vdso.
>> 
>> OK, thanks. Since Andreas has access to a SPARC T4 as of recently, he should
>> be able to test this. Please allow some time for him to review and test the
>> changes, so we can be sure this doesn't cause any serious regressions.
>
> I tested this patch (running Linux in an LDOM under Solaris) and
> measuring the cost of clock_gettime(), running millions of calls. The
> calls takes around 13-15 times as long (from around 82-94 nanoseconds
> per call to around 1220 nanoseconds per call) with this patch compared
> to without, so not an insignificant performance regression in this
> environment.

Ok, thanks a lot for testing! I guess the good news is that I didn't
break functionality here.

Obviously 15x slowdown sounds like a lot, but what I don't know is
whether 1.2µs is actually too slow. Is this CLOCK_REALTIME or some
other clock? I would expect to see a larger difference for the
COARSE version since that saves the hardware access as well.

From what I remember, the original driver for having a VDSO
clock_gettime/gettimeofday was Java applications that call it
too often. Do you know of anyone using Java on performance-critical
sparc64 servers any more, or any other type of workload that
depends on these functions being small?

It is probably not all that hard to convert the VDSO to use the
generic implementation if you remove the runtime patching between
TICK and STICK mode. From the code and the documentation, it
seems that any JPS1 compatible CPU (or newer) uses STICK,
this would be UltraSPARC III (Cheetah), SPARC64 V (Zeus)
and all UltraSPARC T. If you want to give it a try to do the
conversion to the generic VDSO, I could respin my patch to only
remove the older TICK version and the runtime patching but leave
the STICK one. I don't think it's worth my time trying to convert
STICK myself since I have no way of testing it.

Another option would be to start by adding a VDSO for LEON
CPUs using the ASR22:23 upcounter register. This should be
fairly easy to do if you copy the CSR_TIME code from riscv
and replace their __arch_get_hw_counter(), and this is probably more
relevant than the sparc64 version. Once that works, you
can extend it to use STICK on JPS1.

     Arnd