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