[jandrewrogers]

I have not adopted io_uring yet because it isn't clear that it will provide useful performance improvements over linux aio in cases where the disk I/O subsystem is already highly optimized. Where io_uring seems to show a benefit relative to linux aio is more naive software design, which adds a lot of value but is a somewhat different value proposition than has been expressed.

For software that is already capable of driving storage hardware at its theoretical limit, the benefit is less immediate and offset by the requirement of having a very recent Linux kernel.

[shuss]

For regular files, aio works async only if they are opened in unbuffered mode. I think this is a huge limitation. io_uring on the other hand, can provide a uniform interface for all file descriptors whether they are sockets or regular files. This should be a decent win, IMO.

[jandrewrogers]

That was kind of my point. While all of this is true, these are not material limitations for the implementation of high-performance storage engines. For example, using unbuffered file descriptors is a standard design element of databases for performance reasons that remain true.

Being able to drive networking over io_uring would be a big advantage but my understanding from people using it is that part is still a bit broken.

[g8oz]

The ScyllaDB developers wrote up their take here: https://www.scylladb.com/2020/05/05/how-io_uring-and-ebpf-wi...

[jabl]

Those benchmark results are pretty impressive. In particular, io_uring gets the best performance both when the data is in the page cache and when bypassing the cache.

[shuss]

True. Have to agree, here. Although one advantage over aio for block I/O that io_uring will still have is to use polling mode to almost completely avoid system calls.

[wbl]

And works is used advisedly. Certain filesystem edge conditions particularly metadata changes due to block allocation can result in blocking behavior.

[tyingq]

If I understand the premise right, it should be fewer syscalls per IO. So even if it doesn't improve disk I/O, it might reduce CPU utilization.

[matheusmoreira]

It could also be nearly zero system calls per I/O operation. The kernel can poll the submission queue for new entries. This eliminates system call overhead at the cost of higher CPU utilization.

[jandrewrogers]

This is true, but for most intentionally optimized storage engines that syscall overhead is below the noise floor in practice, even on NVMe storage. A single core can easily drive gigabytes per second using the old Linux AIO interface.

It appears to primarily be an optimization for storage that was not well-optimized to begin with. It is not obvious that it would make high-performance storage engines faster.

[loeg]

aio doesn't have facilities for synchronous filesystem metadata operations like open, rename, unlink, etc. If your workload is largely metadata-static, aio is ok. If you need to do even a little filesystem manipulation, io_uring seems like it can provide some benefits.