The beginning of the asynchronous I/O merge?

Ben LaHaise's asynchronous I/O patch has been waiting for inclusion for many months. Asynchronous I/O happens, of course, without blocking the calling process; it also goes directly to or from the user process buffer whenever possible. The feature is used by certain demanding applications, such as relational database systems. Ben's patch is working, and has been shipped in Red Hat's Advanced Server product. But it is not yet part of the mainline kernel.

There are a couple of apparent reasons for this patch's long wait for inclusion. One is that Linus is unconvinced about the value of asynchronous I/O; he thinks there are better ways to solve the problem (see the May 16, 2002 LWN Kernel Page). The other reason is that this patch reaches deeply into the kernel and changes some fundamental interfaces - for example, it changes the read and write functions provided by device drivers. Big changes make Linus (and others) nervous; it is considered preferable to break things multiple times in small pieces.

So now some of the structure needed for asynchronous I/O is being submitted in the requisite small chunks. The first patch simply splits the fput() function into two pieces to simplify its invocation (indirectly) from an interrupt handler.

The second patch is, perhaps, more interesting. Here the wait queue mechanism is being changed in fundamental ways. The first version of this patch simply added a callback function which would be invoked when a wakeup happens on the queue. This callback is needed for the asynchronous I/O subsystem; it needs to know when an I/O operation completes, but it can not block on the wait queue. Following suggestions from Linus, later revisions of the patch have moved some of the wakeup functionality to that callback function. There can even be different callbacks for "exclusive waits" (where only one process should be awakened even if many are waiting) and the standard "wake everybody" variety. By providing different callbacks, kernel subsystems can change the semantics of the wait operation.

Wait queues, in other words, are evolving from a mechanism that puts a process to sleep for a while into a more general event notification mechanism. The immediate application for this mechanism is asynchronous I/O, but it will be interesting to see what others turn up.

---

(Log in to post comments)