Re: [PATCH v7 07/13] LoongArch: Linux Syscall Interface

[WANG Xuerui <i.swmail@xen0n.name>]

On 2022/7/27 19:16, Adhemerval Zanella Netto wrote:
>
> On 27/07/22 02:32, WANG Xuerui wrote:
>> On 2022/7/27 13:27, WANG Xuerui wrote:
>>> Wait. I almost missed this, glad I took an extra look before starting afternoon's $DAY_JOB work...
>>>
>>> On 2022/7/19 09:20, caiyinyu wrote:
>>>> |+#define VDSO_NAME "LINUX_2.6" +#define VDSO_HASH 61765110|
>>> |According to Linux sources [1], this should be "LINUX_5.10" instead, and the hash should be 182947696. The current value is for the old world and will lead to the vDSO being essentially wasted.
>>> |
>>>
>>> |To the Release Manager: do this need a proper patch, or if this can be fixed up in the branch pending inclusion? I can prepare one in short order if that's the proper way.
>>> |
>>>
>>> |[1]: https://github.com/torvalds/linux/blob/v5.19-rc8/arch/loongarch/vdso/vdso.lds.S#L59
>>> |
>>>
>>>
>> Ah. I just saw the branch merged in master.
>>
>> But a quick vdsotest shows the libc version's performance on par with correct vDSO calls:
>>
>> clock-gettime-monotonic: syscall: 183 nsec/call
>> clock-gettime-monotonic:    libc: 44 nsec/call
>> clock-gettime-monotonic:    vdso: 34 nsec/call
>> clock-getres-monotonic: syscall: 152 nsec/call
>> clock-getres-monotonic:    libc: 19 nsec/call
>> clock-getres-monotonic:    vdso: 14 nsec/call
>> clock-gettime-monotonic-coarse: syscall: 172 nsec/call
>> clock-gettime-monotonic-coarse:    libc: 39 nsec/call
>> clock-gettime-monotonic-coarse:    vdso: 29 nsec/call
>> clock-getres-monotonic-coarse: syscall: 154 nsec/call
>> clock-getres-monotonic-coarse:    libc: 18 nsec/call
>> clock-getres-monotonic-coarse:    vdso: 14 nsec/call
>> clock-gettime-monotonic-raw: syscall: 181 nsec/call
>> clock-gettime-monotonic-raw:    libc: 45 nsec/call
>> clock-gettime-monotonic-raw:    vdso: 36 nsec/call
>> clock-getres-monotonic-raw: syscall: 151 nsec/call
>> clock-getres-monotonic-raw:    libc: 19 nsec/call
>> clock-getres-monotonic-raw:    vdso: 14 nsec/call
>> clock-gettime-tai: syscall: 187 nsec/call
>> clock-gettime-tai:    libc: 44 nsec/call
>> clock-gettime-tai:    vdso: 34 nsec/call
>> clock-getres-tai: syscall: 151 nsec/call
>> clock-getres-tai:    libc: 19 nsec/call
>> clock-getres-tai:    vdso: 14 nsec/call
>> clock-gettime-boottime: syscall: 184 nsec/call
>> clock-gettime-boottime:    libc: 44 nsec/call
>> clock-gettime-boottime:    vdso: 34 nsec/call
>> clock-getres-boottime: syscall: 151 nsec/call
>> clock-getres-boottime:    libc: 19 nsec/call
>> clock-getres-boottime:    vdso: 14 nsec/call
>> clock-gettime-realtime: syscall: 181 nsec/call
>> clock-gettime-realtime:    libc: 44 nsec/call
>> clock-gettime-realtime:    vdso: 34 nsec/call
>> clock-getres-realtime: syscall: 151 nsec/call
>> clock-getres-realtime:    libc: 19 nsec/call
>> clock-getres-realtime:    vdso: 14 nsec/call
>> clock-gettime-realtime-coarse: syscall: 179 nsec/call
>> clock-gettime-realtime-coarse:    libc: 40 nsec/call
>> clock-gettime-realtime-coarse:    vdso: 29 nsec/call
>> clock-getres-realtime-coarse: syscall: 154 nsec/call
>> clock-getres-realtime-coarse:    libc: 18 nsec/call
>> clock-getres-realtime-coarse:    vdso: 14 nsec/call
>> getcpu: syscall: 134 nsec/call
>> getcpu:    libc: 20 nsec/call
>> getcpu:    vdso: 13 nsec/call
>> gettimeofday: syscall: 171 nsec/call
>> gettimeofday:    libc: 47 nsec/call
>> gettimeofday:    vdso: 33 nsec/call
>>
>> Which is getting interesting. (This may explain why nobody noticed before the merge.) I think we should still "fix" it, but at this point I'm starting to doubt whether it's a problem in the first place...
>>
> So does it this need to be fixed in the end? The numbers indicates that vDSO is indeed
> being used.

If striving for purity, the bug should definitely get fixed, but again I 
saw in sysdeps/unix/sysv/linux/dl-vdso.h that the dl_vdso_vsym makes use 
of dl_lookup_symbol_x, which states in its docstring:

 > Search loaded objects' symbol tables for a definition of the symbol 
UNDEF_NAME, perhaps with a requested version for the symbol.

I dug a little deeper but can't really verify the "perhaps" part, but 
judging from the doc alone the current behavior may well be expected. 
Maybe you or someone else more familiar with the details could enlighten 
me on this, but indeed vDSO must actually be effective for the 
order-of-magnitude improvement in numbers, hence the inconsistency 
should not be adversely affecting normal operation besides being a minor 
nuisance. We can fix it after 2.36 gets released then.