[PATCH] LoongArch: Add fstat64 and fstatat64.

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

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