Boost application performance using asynchronous I/O-ref

Linux asynchronous I/O is a relatively recent addition to the Linux kernel. It's a standard feature of the 2.6 kernel,but you can find patches for 2.4. The basic idea behind AIO is to allow a process to initiate a number of I/O operations without having to block or wait for any to complete. At some later time,or after being notified of I/O completion,the process can retrieve the results of the I/O.

Before digging into the AIO API,let's explore the different I/O models that are available under Linux. This isn't intended as an exhaustive review,but rather aims to cover the most common models to illustrate their differences from asynchronous I/O. Figure 1 shows synchronous and asynchronous models,as well as blocking and non-blocking models.

Each of these I/O models has usage patterns that are advantageous for particular applications. This section briefly explores each one.

A process that is I/O bound is one that performs more I/O than processing. A CPU-bound process does more processing than I/O. The Linux 2.6 scheduler actually favors I/O-bound processes because they commonly initiate an I/O and then block,which means other work can be efficiently interlaced between them.

One of the most common models is the synchronous blocking I/O model. In this model,the user-space application performs a system call that results in the application blocking. This means that the application blocks until the system call is complete (data transferred or error). The calling application is in a state where it consumes no CPU and simply awaits the response,so it is efficient from a processing perspective.

Figure 2 illustrates the traditional blocking I/O model,which is also the most common model used in applications today. Its behaviors are well understood,and its usage is efficient for typical applications. When the?read?system call is invoked,the application blocks and the context switches to the kernel. The read is then initiated,and when the response returns (from the device from which you're reading),the data is moved to the user-space buffer. Then the application is unblocked (and the?read?call returns).

From the application's perspective,the?read?call spans a long duration. But,in fact,the application is actually blocked while the read is multiplexed with other work in the kernel.

A less efficient variant of synchronous blocking is synchronous non-blocking I/O. In this model,a device is opened as non-blocking. This means that instead of completing an I/O immediately,a?read?may return an error code indicating that the command could not be immediately satisfied (EAGAIN?or?EWOULDBLOCK),as shown in Figure 3.

The implication of non-blocking is that an I/O command may not be satisfied immediately,requiring that the application make numerous calls to await completion. This can be extremely inefficient because in many cases the application must busy-wait until the data is available or attempt to do other work while the command is performed in the kernel. As also shown in Figure 3,this method can introduce latency in the I/O because any gap between the data becoming available in the kernel and the user calling?read?to return it can reduce the overall data throughput.

Another blocking paradigm is non-blocking I/O with blocking notifications. In this model,non-blocking I/O is configured,and then the blockingselect?system call is used to determine when there's any activity for an I/O descriptor. What makes the?select?call interesting is that it can be used to provide notification for not just one descriptor,but many. For each descriptor,you can request notification of the descriptor's ability to write data,availability of read data,and also whether an error has occurred.

The primary issue with the?select?call is that it's not very efficient. While it's a convenient model for asynchronous notification,its use for high-performance I/O is not advised.

（编辑：ASP站长网）