I finally got a 5.4 kernel onto a test box and spent an evening with io_uring, which has been the thing everyone's been excited about all year. First impression: the excitement is justified, but for a reason I didn't expect.
I went in thinking the headline was async I/O done properly, and it is. But the part that actually made me sit up was the syscall count. With the submission and completion queues shared between userspace and the kernel, you can batch a pile of operations and reap their results without crossing into the kernel for each one. On a workload that was death by a thousand read() calls, that's the whole game.
The raw interface is fiddly enough that you don't want to touch it directly, and you don't have to: liburing wraps the queue setup and the memory barriers so you're not hand-rolling those. Even so, the mental model takes a minute. You submit, the kernel works, you collect completions later, and ordering is your problem now.
It's early days and 5.4 is fresh, so I'm not putting it anywhere near production yet. But for the first time in a while a new kernel interface feels like it solves a problem I actually have, rather than one a benchmark has. I'll be coming back to this.