lsr: ls with io_uring • Hacker News Board

Re: lsr: ls with io_uring

#11

Post by superkuh » Fri, Jul 18, 2025, 1:25 PM UTC

SillyUsername wrote: post #3

Love it. I'm trying to understand why all command line tools don't use io_uring. As an example, all my nvme's on usb 3.2 gen 2 only reach 740MB/s peak. If I use tools with aio or io_uring I get 1005MB/s. I know I may not be copying many files simultaneously every time, but the queue length strategies and the fewer locks also help I guess.

One reason is so that they work in all linux environments rather than just bleeding edge installs from the last couple years.

Re: lsr: ls with io_uring

#12

Post by Bender » Fri, Jul 18, 2025, 1:25 PM UTC

I am curious what would happen if ls and other commands were replaced using io_uring and kernel.io_uring_disabled was set to 1. Would it fall back to an older behavior or would the ability to disable it be removed?

Re: lsr: ls with io_uring

#13

Post by eviks » Fri, Jul 18, 2025, 1:26 PM UTC

ta988 wrote: post #7

fermuch wrote: post #4

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

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

Is there a noticeable benefit of this huge syscall reduction?

Re: lsr: ls with io_uring

#14

Post by neuroelectron » Fri, Jul 18, 2025, 1:27 PM UTC

There used to be lsring by Jens Axboe (author of io_uring), but it no longer exists. This is more extreme than abandoning the project. Perhaps there is some issue with using io_uring this way, perhaps vulnerabilities are exposed.

Re: lsr: ls with io_uring

#15

Post by tyingq » Fri, Jul 18, 2025, 1:28 PM UTC

SillyUsername wrote: post #3

Love it. I'm trying to understand why all command line tools don't use io_uring. As an example, all my nvme's on usb 3.2 gen 2 only reach 740MB/s peak. If I use tools with aio or io_uring I get 1005MB/s. I know I may not be copying many files simultaneously every time, but the queue length strategies and the fewer locks also help I guess.

Probably historical preference for portability without a bunch of #ifdef means platform+version-specific stuff is very late to get adopted. Though, at this point, the benefit of portability across various posixy platforms is much lower.

Re: lsr: ls with io_uring

#16

Post by Imustaskforhelp » Fri, Jul 18, 2025, 1:28 PM UTC

eviks wrote: post #13

ta988 wrote: post #7

Earlier quoted context omitted.

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

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!

Re: lsr: ls with io_uring

#17

Post by never_inline » Fri, Jul 18, 2025, 1:34 PM UTC

SillyUsername wrote: post #3

Love it. I'm trying to understand why all command line tools don't use io_uring. As an example, all my nvme's on usb 3.2 gen 2 only reach 740MB/s peak. If I use tools with aio or io_uring I get 1005MB/s. I know I may not be copying many files simultaneously every time, but the queue length strategies and the fewer locks also help I guess.

Poe's law hits again.

Re: lsr: ls with io_uring

#18

Post by rkangel » Fri, Jul 18, 2025, 1:37 PM UTC

This was more interesting for the tangled.sh platform it's hosted on. Wasn't aware of that!

Re: lsr: ls with io_uring

#19

Post by arghwhat » Fri, Jul 18, 2025, 1:41 PM UTC

neuroelectron wrote: post #14

There used to be lsring by Jens Axboe (author of io_uring), but it no longer exists. This is more extreme than abandoning the project. Perhaps there is some issue with using io_uring this way, perhaps vulnerabilities are exposed.

> Perhaps there is some issue with using io_uring this way, perhaps vulnerabilities are exposed.

... no. It's just not interesting or particularly valuable to optimize ls, and Jens probably just used it as a demo and didn't want to keep it around.

Re: lsr: ls with io_uring

#20

Post by Retr0id » Fri, Jul 18, 2025, 1:43 PM UTC

tyingq wrote: post #15

SillyUsername wrote: post #3

Love it. I'm trying to understand why all command line tools don't use io_uring. As an example, all my nvme's on usb 3.2 gen 2 only reach 740MB/s peak. If I use tools with aio or io_uring I get 1005MB/s. I know I may not be copying many files simultaneously every time, but the queue length strategies and the fewer locks also help I guess.

Probably historical preference for portability without a bunch of #ifdef means platform+version-specific stuff is very late to get adopted. Though, at this point, the benefit of portability across various posixy platforms is much lower.

Has anyone written an io_uring "polyfill" library with fallback to standard posix-y IO? It could presumably be done via background worker threads - at a perf cost.