[PATCH] LoongArch: Add fstat64 and fstatat64.

[caiyinyu]

在 2024/9/12 下午4:17, Miao Wang 写道:
>
>> 2024年9月12日 16:08，caiyinyu <caiyinyu@loongson.cn> 写道：
>>
>>
>> 在 2024/9/12 上午2:00, Miao Wang 写道:
>>>> 2024年9月12日 00:50，Miao Wang <shankerwangmiao@gmail.com> 写道：
>>>>
>>>>> 2024年9月11日 17:40，caiyinyu <caiyinyu@loongson.cn> 写道：
>>>>>
>>>>> In Linux 6.11, the fstat (80) and newfstatat (79) syscalls have been
>>>>> reintroduced. The definitions of these two syscalls have already been
>>>>> backported to version 6.10.6 in the stable tree.
>>>>>
>>>>> In this patch, we are adding dynamically probed implementations of
>>>>> fstat64 and fstatat64 specifically for syscalls 79 and 80. This ensures
>>>>> compatibility while maintaining relatively good performance on kernels
>>>>> that both support and do not support syscalls 79 and 80.
>>>>>
>>>>> By running an experiment where we invoke fstat64 and fstatat64 100
>>>>> million times, we gathered the following efficiency statistics:
>>>>>
>>>>> 1. On kernels that support syscalls 79 and 80 (tested on version
>>>>>   6.10.6), fstat64 and fstatat64 can directly invoke these syscalls
>>>>>   [1]. The time overhead of our dynamic probing implementation
>>>>>   increased by 0.5%-2.5% compared to directly calling the syscalls.
>>>>> 2. On kernels that support syscalls 79 and 80 (tested on version
>>>>>   6.10.6), our dynamically probed implementation reduces the time
>>>>>   overhead by more than 60% compared to directly invoking the statx
>>>>>   (291) syscall.
>>>>> 3. On kernels that do not support syscalls 79 and 80 (tested on version
>>>>>   6.8.0), fstat64 and fstatat64 fall back to using the statx (291)
>>>>>   syscall (as before). In this case, the overhead of our dynamic
>>>>>   probing implementation increased by 0.1%-1.3% compared to directly
>>>>>   invoking statx.
>>>> Hi, I tried to reproduce your test result, by invoking fstat(2) for 1M times,
>>>> repeated by 100 times. The test was carried out on 3A6K, using 6.11-rc7 kernel.
>>>> The result is:
>>>>
>>>> fstat using statx(fd, "", AT_EMPTY_PATH) (current glibc implementation)
>>>> mean: 210420528.100000(ns), sigma: 996145.440248(ns)
>>>>
>>>> statx(fd, NULL, AT_EMPTY_PATH) (for comparison)
>>>> mean: 199410620.600000(ns), sigma: 111561.012101(ns)
>>>>
>>>> fstat using statx(fd, NULL, AT_EMPTY_PATH) (The implementation I proposed)
>>>> mean: 208258640.700000(ns), sigma: 468451.704836(ns)
>>>>
>>>> fstat using fstat(fd) (Your patch)
>>>> mean: 192936673.800000(ns), sigma: 251927.136307(ns)
>>>>
>>>> As we can see in the result, the implementation using fstat is 8.31% faster
>>>> than the current implementation, instead of "reducing the time overhead by
>>>> more than 60%".
>>> I did another test on 6.10.7, using the current glibc implementation, i.e.
>>> statx(fd, "", AT_EMPTY_PATH), and got the following result:
>>>
>>> mean: 603344203.300000(ns), sigma: 715246.975336(ns)
>>>
>>> If we use this as the baseline, we can get the following summary:
>>>
>>> fstat(fd): 68.02% less time
>>> statx(fd, NULL, AT_EMPTY_PATH): 65.48% less time
>>> statx(fd, "", AT_EMPTY_PATH) (nothing is changed in glibc, only upgrade the
>>>    kernel to 6.11): 65.12% less time
>>>
>>> As a result, the performance gain is similar comparing using fstat(fd) and
>>> statx(fd, NULL, AT_EMPTY_PATH).
>>>
>>>> I prefer introducing dynamic probing of statx(fd, NULL, AT_EMPTY_PATH), which
>>>> can benefit all 32-bit platforms relying on statx for 64-bit timestamps[2], as
>>>> well as 64-bit loongarch, not only for performance, but also for seccomp
>>>> sandboxing. Furthermore, by doing so, we can eliminate the need of maintaining
>>>> our own copy of fstat in loongarch.
>>> To conclude, the question would be whether it is worthy to have a separately
>>> maintained fstat in loongarch for the 2.54% performance difference.
>> The key point here is that the dynamic probing solution can run directly on
>> kernels without support for the 79 and 80 system calls (which is essential for
>> us). However, after updating arch-syscall.h, the glibc compiled using Miao
>> plan[1] cannot run on kernels that do not support the 79 and 80 system calls.
> Why? In my patch, when the requested kernel compatibility version is below
> 6.10.6, __ASSUME_LOONGARCH_NEWSTAT will not be defined, and the definition
> of the syscalls __NR_fstat and __NR_newfstatat will be undef-ed. So the
> implementation will choose to use statx() in the compile time, and thus able to
> run on previous kernels.


When glibc is compiled on kernel versions >= 6.10.6 (with 
--enable-kernel=6.10.6), it uses the 79 and 80 system calls. These 
precompiled libraries cannot work on kernels that do not support the 79 
and 80 system calls, unless they are recompiled. Unfortunately, we have 
to handle this situation.

>
> Cheers,
>
> Miao Wang
>
>>
>>>> [2]: [PATCH v5] linux: Add linux statx(fd, NULL, AT_EMPTY_PATH) support
>>>> https://sourceware.org/pipermail/libc-alpha/2024-August/159499.html
>>>>
>>>>
>>>> Cheers,
>>>>
>>>> Miao Wang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://sourceware.org/pipermail/libc-alpha/attachments/20240912/49e58502/attachment-0001.htm>