[PATCH] LoongArch: Add fstat64 and fstatat64.

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

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