Linux2.6 -- Linus elevator

In order to process requests from the IO layer, the kernel needs to be optimized accordingly, because when there are many requests, and there are several request blocks in one, if these requests are processed in order, it is undoubtedly a great time overhead. Therefore, we need to seek a way to handle this situation (not just this case, of course ), this article introduces Linus elevator, the classic I/O scheduling program in Linux, which is named by Linus, the inventor of Linux. In kernel 2.4, Linus elevator is the default IO scheduler. Although it was replaced by two other schedulers in the later kernel version 2.6, because the scheduler is simpler than the later scheduler, and many of their functions are similar, therefore, it can be used as an excellent introductory program.

First, explain why this scheduling program is called elevator scheduling.

As we all know, when reading data on a disk, we must first address the head and find the location (sector) of the data storage ). This scheduling algorithm considers that it is better to schedule requests in the order of head movement. when the end of the disk is reached, the head is switched to the other end and then moved to the other end, as shown in the following figure:

The Linus elevator can be combined to sort and pre-processed. When a new request is added to the queue, it first checks whether the other pending requests can be merged with the new requests. The Linus elevator I/O scheduler can merge the request forward and backward. The merge type describes whether the request is forward or backward, which is connected to an existing request. If a new request is directly connected to an existing request, it is merged forward. On the contrary, if a request is connected to an existing request, it is merged backward. In view of the distribution characteristics of files and the typical IO operation execution method, the merge ahead is much less than the merge backward, but the Linus elevator will still check both types of merge.

If the merge attempt fails, you need to find possible insertion points. If it is found, the new request will be inserted to this point. If there is no suitable location, the new request will be added to the end of the queue.

All in all, when a request is added to the queue, four operations may occur. They are:

1> If an adjacent disk sector operation request already exists in the queue, the new request will be merged with the existing request.

2> if a long-lived request exists in the queue, the new request will be inserted to the end of the queue to prevent other old requests from hunger.

3> if a proper Insertion Location exists in the order of the slice method in the queue, new requests will be inserted to this location to ensure that the requests in the queue are arranged in the order of the physical locations of the accessed disk.

4> if no suitable request Insertion Location exists in the queue, the request will be inserted to the end of the queue.

Recommended reading:

Common commands for Linux file systems and file operations

Linux File System limits ulimit usage

Detailed explanation of file time attribute in Linux File System