Why glibc's fstat() is slow [LWN.net]

Why glibc's fstat() is slow

Posted Sep 15, 2023 14:51 UTC (Fri) by hmh (subscriber, #3838)
In reply to: Why glibc's fstat() is slow by izbyshev
Parent article: Why glibc's fstat() is slow

Looks like it would be easy enough to fix, if there's a will to do so. In fact, now would be the ideal time to do it, since you also want to ensure any libc that is ported to those arches will try to use the faster syscall instead of the generic one [where available].

I wonder if people looked at what glibc would use when they were bootstrapping these two arches, and decided to not implement the more specialized, less-generic (but faster!) members of the stat family of syscalls because glibc would not use them...

to post comments

Why glibc's fstat() is slow

Posted Sep 18, 2023 13:13 UTC (Mon) by eru (subscriber, #2753) [Link]

I wonder if people looked at what glibc would use when they were bootstrapping these two arches,

What I don't get is why would they have to think about that code at all when bootstrapping. There is an architecturally neutral implementation of fstat() and friends, and all the person working on the porting should need to do is to connect each system call implementation to the low-level mechanism the particular architecture employs to jump from userland to the kernel.

Why glibc's fstat() is slow

Posted Oct 7, 2023 14:54 UTC (Sat) by izbyshev (subscriber, #107996) [Link]

I looked a bit further, and it turns out that the original statx implementation did support passing NULL filename to emulate fstat, but this support was explicitly dropped in [1].

It feels really weird that Linus bashed glibc for "being silly" but merged this change... OTOH back in 2017 archs without fstat syscall didn't exist, so it wasn't a problem for C libraries.

[1] https://git.kernel.org/torvalds/c/1e2f82d1e9d12223b4cbd1f...