The asynchronous I/O core

Ben responded with a patch implementing the core part of the AIO subsystem. It is far from a full implementation - there are no device driver or filesystem changes in the patch. But it is enough to get a sense for where the AIO development is going.

This patch does not, at this time, make all I/O asynchonous within the kernel (as had been discussed at Kernel Summit). Instead, devices and filesystems must implement the new aio_read, aio_write, and aio_fsync operations in the file_operations structure to be able to support asynchronous operations. This patch can thus, at this point, go into the system without actually breaking anything.

That may change when the rest of the AIO code is posted. This patch provides the mechanism for submitting, tracking, and cancelling asynchronous I/O operations - actually executing those operations will come later. A new io_submit system call provides for the initiation of asynchronous I/O requests; it takes an array of structures describing what is to be done. Whenever an application wants to fire off an asynchronous read or write, it fills in a iocb structure with an "opcode," information on the buffer, etc. and passes it to io_submit. (Of course, the application will likely call a library function like aio_read which handles these details).

io_submit does some validation and bookkeeping, then passes the requests on to the new file_operations methods. For now, they disappear into a cloud of missing code for execution. When the operation has completed, successfully or not, the internal function aio_complete is called with the final status. That status (and associated information) is stored in a circular buffer; applications can extract this information from the buffer with the new io_getevents system call.

Interestingly, some of the structure is there to allow this circular buffer to be mapped into user space. Then applications could obtain their I/O completion information without the need for a system call. The implementation of this feature is not yet complete, however.

Much of the rest of the code posted at this point concerns itself with cancellation of asynchronous I/O requests - either by application request, or when the application exits.

What is missing is the implementation of the AIO operations themselves. Previous versions of this patch provided generic versions of the aio_read and aio_write operations that handled much of the low-level work. They would start by calling the standard read or write operations, but with a twist: those operations were changed to take an extra flags argument. If flags contains F_ATOMIC, the I/O operation must be completed without sleeping, or not at all. In the first case, the operation is done and the application can be notified.

Life is often not that easy, though - usually it is necessary to wait for I/O operations. The application does not want to wait, of course, or it would not be using asynchronous I/O. The older AIO patch would create a kvec structure describing the operation - it contains a pointer to the physical page holding the user buffer, a length, and an offset. Then one of the new kvec_read or kvec_write operations would be called to start the work. These operations also need to be atomic (no sleeping), and must arrange to call aio_complete when the job is done.

This is the part of the patch which breaks everything, of course - even devices and filesystems which have no intention of supporting asynchronous I/O must take the new flags argument on read and write. It will be interesting to see how this part of the AIO patch has changed over the last few months. If the kernel is really going to shift to asynchronous operations as the default way of doing things internally, there could be some fun surprises there.