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

Why glibc's fstat() is slow

Posted Sep 14, 2023 20:00 UTC (Thu) by izbyshev (subscriber, #107996)
Parent article: Why glibc's fstat() is slow

For newer architectures (riscv32, loongarch), the simpler fstat syscall doesn't exist at all[1], and statx is the only option to implement fstat, forcing the useless path check. So no, it's not just a glibc problem, at least if we're looking beyond x86-64.

[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/...

to post comments

Why glibc's fstat() is slow

Posted Sep 15, 2023 6:23 UTC (Fri) by eru (subscriber, #2753) [Link] (4 responses)

I find it very strange that this depends on the CPU architecture at all. The fstat() and its relatives work on the file system, which is at much higher level than what architecture differences would naturally affect.

Why glibc's fstat() is slow

Posted Sep 15, 2023 14:08 UTC (Fri) by izbyshev (subscriber, #107996) [Link] (3 responses)

This is not due to architectural differences, but due to the standard kernel policy of supporting only the most general version of the syscall[1]. In this case, apparently, performance implications of having only statx were not considered.

[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/...

Why glibc's fstat() is slow

Posted Sep 15, 2023 14:51 UTC (Fri) by hmh (subscriber, #3838) [Link] (2 responses)

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

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

Why glibc's fstat() is slow

Posted Sep 25, 2023 18:29 UTC (Mon) by BenHutchings (subscriber, #37955) [Link]

The statx() system call is also the only Y2038-safe stat system call on 32-bit architectures (aside from x32).