lsr: ls with io_uring

The link isn't working for me. For those who were able to see it: does it improve anything by using that instead of what ls does now??

Hm interesting, it worked for me.

70% faster, but more importantly 35x times less syscalls.

It improves the latency of ls calls.

Is there a noticeable benefit of this huge syscall reduction?

Yes I just checked it after installing strace

strace -c ls gave me this

100.00 0.002709 13 198 5 total

strace -c eza gave me this

100.00 0.006125 12 476 48 total

strace -c lsr gave me this

100.00 0.001277 33 38 total

So seeing the number of syscalls in the calls directory

198 : ls

476 : eza

33 : lsr

A meaningful difference indeed!

Why do you say more importantly? The time is all that matters, I think.

That's just observing there is a difference, not explaining why that's a good thing.

%70 faster = you wait less

35x less system calls = others wait less for the kernel to handle their system calls

> 35x less system calls = others wait less for the kernel to handle their system calls

That isn't how it works. There isn't a fixed syscall budget distributed among running programs. Internally, the kernel is taking many of the same locks and resources to satisfy io_uring requests as ordinary syscall requests.

More system calls mean more overall OS overhead eg. more context switches, or as you say more contention on internal locks etc.

Also, more fs-related system calls mean less available kernel threads to process these system calls. eg. XFS can paralellize mutations only up to its number of allocation groups (agcount)

> More system calls mean more overall OS overhead [than the equivalent operations performed with io_uring]

Again, this just isn't true. The same "stat" operations are being performed one way or another.

> Also, more fs-related system calls mean less available kernel threads to process these system calls.

Generally speaking sync system calls are processed in the context of the calling (user) thread. They don't consume kernel threads generally. In fact the opposite is true here -- io_uring requests are serviced by an internal kernel thread pool, so to the extent this matters, io_uring requests consume more kernel threads.

> Again, this just isn't true.

Again, it just is true.

More fs-related operations mean less kthreads available for others. More syscalls means more OS overhead. It's that simple.

syscalls are expensive and their relative latency compared with the rest of code only grow especially in view of mitigations against cache-related and other other hardware bugs.