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.
