←back to thread

lsr: ls with io_uring

(rockorager.dev)
335 points mpweiher | 3 comments | | HN request time: 0.73s | source
Show context
api ◴[] No.44605484[source]
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 get by removing a ton of syscalls?

Or am I failing to understand something about the performance nuances here?

replies(3): >>44605692 #>>44605822 #>>44605934 #
1. yencabulator ◴[] No.44605934[source]
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).

replies(1): >>44607754 #
2. api ◴[] No.44607754[source]
In a single threaded flow your buffer pool is just the buffer you were given, and you don't return until the call completes. There are no actual concurrent calls in the ring. All you're doing is using io_uring to avoid syscall.

Other replies lead me to believe it's not worth doing though, that it would not actually save syscalls and might make things worse.

replies(1): >>44609153 #
3. yencabulator ◴[] No.44609153[source]
Can you use io_uring in a way that doesn't gain the benefits of using it? Yes. Does the traditional C/POSIX API force you into that pattern? Almost certainly.