|
|
Log in / Subscribe / Register

The rapid growth of io_uring

The rapid growth of io_uring

Posted Jan 25, 2020 1:14 UTC (Sat) by wahern (subscriber, #37304)
Parent article: The rapid growth of io_uring

Classic Unix I/O is inherently synchronous. As far as an application is concerned, an operation is complete once a system call like read() or write() returns, even if some processing may continue behind its back. There is no way to launch an operation asynchronously and wait for its completion at some future time — a feature that many other operating systems had for many years before Unix was created.

Unix historically didn't have asynchronous disk I/O, and this effected the architecture of subsystems and drivers. Linux still doesn't have asynchronous buffered disk I/O. All you're doing is offloading the operation to a thread pool in the kernel, which performs the operation synchronously, rather than a thread pool in user land.

Once upon a time Linux eschewed complex APIs in favor of making the basic primitives--forking, threading, syscalls, etc--as fast and efficient as possible. And that's perhaps why all the earlier proposals never never made it in--the original strategy was still paying dividends and reduced the pressures that enterprise systems never could cope with. A kernel-land I/O thread pool couldn't schedule I/O any better than a user land thread pool, and if it could the solution was to make it so the user land thread pool could just as well, not to actually relent and expose a specialized I/O thread pool kernel construct.

So now that Linux is moving in the direction of increasingly complex, leaky APIs to cover the performance gap, treading the old waters of enterprise Unix, what does that imply, if anything, about the evolution of Linux and the state of hardware. Are we really better off shifting so much complexity into the kernel? From a security perspective that seems highly doubtful. Are we really better off from a performance perspective? If Linux is abdicating its dogged pursuit of performance improvements, don't we know where this road leads? Or maybe Linux finally hit the wall of what the Unix process and I/O model could fundamentally provide. io_uring is what you'd build as an IPC primitive for a very high performance microkernel. Why keep all this complexity in one, insecure address space when we can finally disperse it across different processes, using a new process model that boxes and aggregates resources in a fundamentally different way.


to post comments

The rapid growth of io_uring

Posted Jan 27, 2020 13:26 UTC (Mon) by ermo (subscriber, #86690) [Link]

> Why keep all this complexity in one, insecure address space when we can finally disperse it across different processes, using a new process model that boxes and aggregates resources in a fundamentally different way.

Are you suggesting that it might be worth it to experiment with making Linux a hybrid (macro/micro) kernel and use io_uring as the transport between separate kernel "daemon" processes, moving forward with the separation by splitting out one subsystem at a time?

If not, could you perhaps outline what you had in mind? Inquiring minds would like to know.

The rapid growth of io_uring

Posted Jan 29, 2020 20:13 UTC (Wed) by notriddle (subscriber, #130608) [Link]

> So now that Linux is moving in the direction of increasingly complex, leaky APIs to cover the performance gap, treading the old waters of enterprise Unix, what does that imply, if anything, about the evolution of Linux and the state of hardware.

What it says about the state of hardware is easy.

Meltdown mitigations made context switching more expensive, and SSDs made the actual I/O cheaper. At some point, you're spending almost as much time context switching as you are doing actual work, and there's nothing Linux can do about it because it's all tied up in the architecture of the MMU and the processor's cache. Thus, it now makes sense to design the interface around reducing the number of context switches at all cost, instead of just assuming that the cost of doing the actual I/O will dominate.

The rapid growth of io_uring

Posted Jan 29, 2020 20:25 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]

> Unix historically didn't have asynchronous disk I/O, and this effected the architecture of subsystems and drivers. Linux still doesn't have asynchronous buffered disk I/O. All you're doing is offloading the operation to a thread pool in the kernel, which performs the operation synchronously, rather than a thread pool in user land.
That's not quite true, the BIO layer is already asynchronous (with its own scheduler and everything). And that's where the most of the waiting goes.

And it's not like the VFS layer is impossible to implement asynchronously, it's just that before now it was not needed at all.


Copyright © 2026, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds