[t00]

There are examples of cat and cp using io_uring. What are the chances of having io_uring utilised by standard commands to improve overall Linux performance? I presume GNU utils are not Linux specific hence such commands are programmed for a generic *nix.

Another one is I could not find a benchmark with io_uring - this would confirm the benefit of going from epoll.

[mahkoh]

>Another one is I could not find a benchmark with io_uring - this would confirm the benefit of going from epoll.

One of the advantages of io_uring, unrelated to performance, is that it supports non-blocking operations on blocking file descriptors.

Using io_uring is the only method I recall to bypass https://gitlab.freedesktop.org/wayland/wayland/-/issues/296. This issue deals with having to operate on untrusted file descriptors where the blocking/non-blocking state of the file descriptions might be manipulated by an adversary at any time.

[kragen]

So does the FIONREAD ioctl, but it's not a general solution. (According to https://news.ycombinator.com/item?id=42617719, neither is io_uring yet.) Thanks for the link to the horrifying security problem!

[o11c]

I thought for sure this was wrong, but when I actually checked the docs, it turns out that `RWF_NOWAIT` is only valid for `preadv2` not `pwritev2`. This should probably be fixed.

For sockets, `MSG_DONTWAIT` works with both `recv` and `send`.

For pipes you should be able to do this with `SPLICE_F_NONBLOCK` and the `splice` family, but there are weird restrictions for those.

[lukeh]

Also useful for things like SPI with only blocking user space API.

[fweimer]

GNU coreutils already has tons of Linux-specific code. But it would be a bit of a kernel fail if io_uring were faster or other preferable to copy_file_range for cp (at least for files that do not have holes).

[Sesse__]

Not at all; with io_uring, you can copy multiple files in parallel (and in fewer syscalls), which is a huge win for small files.

[kragen]

On a hard disk, copying multiple files in parallel is likely to make the copy run slower because it spends more time seeking back and forth between the files (except for small files). Perhaps that isn't a problem with SSDs? It seems like you'd still end up with the data from the different files interleaved in the erase blocks currently being written instead of contiguous, which seems like it would slow down all subsequent reads of those files (unless they're less than a page in size).

[Sesse__]

> On a hard disk, copying multiple files in parallel is likely to make the copy run slower because it spends more time seeking back and forth between the files (except for small files).

Certainly not; it's likely to make it run faster, since you can use the elevator algorithm more efficiently instead of seeking back and forth between the files. You can easily measure this yourself by using comparing wcp, which uses io_uring, and GNU cp (remember to empty the cache between each run).

[kragen]

Hmm, that's interesting! I don't have a hard disk handy right now, unfortunately.