fstat(2) penalized by using newfstatat(6, "", buf, AT_EMPTY_PATH)
Mateusz Guzik
mjguzik@gmail.com
Mon Sep 4 09:55:37 GMT 2023
Commit 4d97cc8cf3da ("io: Remove xstat implementations") reimplemented
fstat entry point on top of newfstatat (as opposed to newfstat).
This comes with a significant performance penalty as it induces a lot
of work on kernel side to handle the path, which is additionally
slowed down on x86-64 due to SMAP handling.
Here are sample results from calling newfstatat vs newfstat on Sapphire Rapids:
newfstatat 5088199
newfstat 8540383 (+67%)
Are there any problems switching it back to newfstat at least for x86-64?
If you want to bench yourself you can grab will-it-scale +
https://github.com/antonblanchard/will-it-scale/pull/35/files + patch
up one of the testcases to call newfstat directly: int error =
syscall(5, fd, &sb);
Note if you bench yourself and have a CPU significantly impacted by
mitigations (e.g., meltdown) the difference may be very small in your
setup.
--
Mateusz Guzik <mjguzik gmail.com>
More information about the Libc-alpha
mailing list