Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

lsr: ls with io_uring

rockorager.dev

Post reply on HN
Print view View original

71–80 of 177 posts

Re: lsr: ls with io_uring

#71

Post by otterley »

0x000xca0xfe wrote: post #62
maplant wrote: post #52

This seems more interesting as demonstration of the amortized performance increase you'd expect from using io_uring, or as a tutorial for using it. I don't understand why I'd switch from using something like eza. If I'm listing 10,000 files the difference is between 40ms and 20ms. I absolutely would not notice that for a single invocation of the command.

Well I have a directory with a couple million JSON files and ls/du take minutes. Most of the coreutils are not fast enough to actually utilize modern SSDs.

What’s the filesystem type? Ext4 suffers terrible lookup performance with large directories, while xfs absolutely flies.

Re: lsr: ls with io_uring

#72

Post by plq »

loeg wrote: post #64
plq wrote: post #58

Earlier quoted context omitted.

%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)

Re: lsr: ls with io_uring

#73

Post by JdeBP »

WorldMaker wrote: post #36
mschuster91 wrote: post #25

Earlier quoted context omitted.

> Why does this require inventing lsr as an alternative to ls instead of making ls use io_uring? Good luck getting that upstreamed and accepted. The more foundational the tools (and GNU coreutils definitely is foundational), the more difficult that process will be. Releasing a standalone utility makes iteration much faster, partially because one is not bound to the release cycles of distributions.

In the history of Unix its also a common way to propose tool replacements, for instance how `less` became `more` on most systems, or `vim` became the new `vi` which in its day became the new `ed`.

Yes and no. We don't really have the equivalent of comp.sources.unix nowadays, which is where the early versions of those occurred, and comp.sources.unix did not take just anything. Rich Salz had rules.

Plus, since I actually took stevie and screen and others from comp.sources.unix and worked on them, and wasn't able to even send my improvements to M. Salz or the original authors at all, from my country, I can attest that contributing improvements had hurdles just as large to overcome back then as there exist now. They're just different.

Re: lsr: ls with io_uring

#74

Post by otterley »

tln wrote: post #50

The times seem sublinear, 10k files is less than 10x 1k files. I remember getting in to a situation during the ext2 and spinning rust days where production directories had 500k files. ls processes were slow enough to overload everything. ls -F saved me there. And filesystems got a lot better at lots of files. What filesystem was used here? It's interesting how well busybox fares, it's written for size not speed iirc?

Ext2 never got better with large directories even with SSDs (this includes up to ext4). The benchmarks don’t include the filesystem type, which is actually extremely important when it comes to the performance of reading directories.

Re: lsr: ls with io_uring

#75

Post by mprovost »

ninkendo wrote: post #9

I wonder how it performs against an NFS server with lots of files, especially one over a kinda-crappy connection. Putting an unreliable network service behind blocking POSIX syscalls is one of the main reasons NFS is a terrible design choice (as can be seen by anyone who's tried to ctrl+c any app that's reading from a broken NFS folder), but I wonder if io_uring mitigates the bad parts somewhat.

The designers of NFS chose to make a distributed system emulate a highly consistent and available system (a hard drive), which was (and is) a reasonable tradeoff. It didn't require every existing tool, such as ls, to deal with things like the server rebooting while listing a directory. (The original NFS protocol is stateless, so clients can survive server reboots.) What does vi do when the server hosting the file you're editing stop responding? None of these tools have that kind of error handling.

I don't know how io_uring solves this - does it return an error if the underlying NFS call times out? How long do you wait for a response before giving up and returning an error?

Re: lsr: ls with io_uring

#76

Post by yencabulator »

api wrote: post #61

Why isn’t it possible — or is it — to make libc just use uring instead of syscall? Yes I know uring is an async interface, but it’s trivial to implement sync behavior on top of a single chain of async send-wait pairs, like doing a simple single threaded “conversational” implementation of a network protocol. It wouldn’t make a difference in most individual cases but overall I wonder how big a global speed boost you’d…

Not speaking of ls which is more about metadata operations, but general file read/write workloads:

io_uring requires API changes because you don't call it like the old read(please_fill_this_buffer). You maintain a pool of buffer that belong to the ringbuffer, and reads take buffers from the pool. You consume the data from the buffer and return it to the pool.

With the older style, you're required to maintain O(pending_reads) buffers. With the io_uring style, you have a pool of O(num_reads_completing_at_once) (I assume with backpressure but haven't actually checked).

Re: lsr: ls with io_uring

#77

Post by wtallis »

ninkendo wrote: post #65
api wrote: post #61

Why isn’t it possible — or is it — to make libc just use uring instead of syscall? Yes I know uring is an async interface, but it’s trivial to implement sync behavior on top of a single chain of async send-wait pairs, like doing a simple single threaded “conversational” implementation of a network protocol. It wouldn’t make a difference in most individual cases but overall I wonder how big a global speed boost you’d…

In order to make this work, libc would have to: - Start some sort of async executor thread to service the io_uring requests/responses - Make it so every call to "normal" syscalls causes the calling thread to sleep until the result is available (that's 1 syscall) - When the executor thread gets a result, have it wake up the original thread (that's another syscall) So you're basically turning 1 syscall into 2 in order…

You don't need to start spawning new threads to use io_uring as a backend for synchronous IO APIs. You just need to set up the rings once, then when the program does an fwrite or whatever, that gets implemented as sending a submission queue entry followed by a single io_uring_enter syscall that informs the kernel there's something in the submission queue, and using the arguments indicating that the calling process wants to block until there's something in the completion queue.

Re: lsr: ls with io_uring

#78

Post by fpoling »

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.

io_uring is the asynchronous interface and that requires to use even-based architecture to use it effectively. But many command-line tools are still written is a straightforward sequential style. If C would have async or similar mechanism to pretend doing async programming sequentially, it would be easier to port. But without that a very significant refactoring is necessary.

Besides, io_uring is not yet stable and who knows may be in 10 years it will be replaced by yet another mechanism to take advantage of even newer hardware. So simply waiting for io_uring prove it is here to stay is very viable strategy. Besides in 10 years we may have tools/AI that will do the rewrite automatically...

Re: lsr: ls with io_uring

#80

Post by mschuster91 »

s1mplicissimus wrote: post #57
KPGv2 wrote: post #42

Earlier quoted context omitted.

> the value of software appears when it's run, not when it's written Have you ever tried to contribute to open source projects? The question was why wouldn't someone writing software not take the route likely to end in rejection/failure. I don't know about you, but if I write software, I am not going to write it for a project whose managers will make it difficult for my PR to be accepted, and that 99% likely it never…

> Have you ever tried to contribute to open source projects? yes, and it was often painful enough to make me consider very well wether I want to bother contributing. I can only imagine how terrible the experience must be at a core utility such as ls. > The question was why wouldn't someone writing software not take the route likely to end in rejection/failure Obviously they wouldn't - in my comment I assumed that the…

> The older OSS projects become, the more they fossilize too - and that makes it more annoying to contribute.

Newer ones can be just as braindead, if they came out of some commercial entity. CLAs and such.

Post reply on HN