Read Anticipation Heuristic

In the case that read anticipation is enabled (antic_expire 0), read requests are dispatched to the disk or RAID controller one at a time. At the end of each read request, the I/O scheduler examines the next read request from the sorted read list (an actual rb-tree). If the next read request belongs to the same process as the request that just completed, or if the next request in the queue is close (data block-wise) to the just-completed request, the request is dispatched immediately. The statistics of average think-time and seek distance available for the process that just completed are examined. These statistics are associated with each process but are not associated with a specific I/O device.

To illustrate, the approach works more efficiently if there is a one-to-one correlation between a process and a disk. In the case that a process is actively working I/O requests on separate devices, the actual statistics reflect a combination of the I/O behavior across all the devices, skewing the statistics and therefore distorting the facts. If the AS scheduler guesses right, very expensive seek operations can be omitted, and hence the overall I/O throughput benefits tremendously. In the case that the AS scheduler guesses wrong, the antic_expire time is wasted. In an environment that consists of larger (hardware striped) RAID systems and tag command queuing (TCQ)-capable disk drives, it is more beneficial to dispatch an entire batch of read requests and let the controllers and disk do their magic.

From a physical disk perspective, to locate specific data, the disk drive's logic requires the cylinder, the head, and the sector information. The cylinder specifies the track on which the data resides. Based on the layering technique used, the tracks underneath each other form a cylinder. The head information identifies the specific read/write head, and therefore the exact platter. The search is then narrowed down to a single track on a single platter. Ultimately, the sector value reflects the sector on the track, and the search is completed.

Contemporary disk subsystems do not communicate in terms of cylinders, heads, and sectors. Instead, modern disk drives map a unique block number over each cylinder/head/sector construct. Therefore, that unique reference number identifies a specific cylinder/head/sector combination. Operating systems address the disk drives by utilizing these block numbers. Hence the disk drive is responsible for translating the block number into the appropriate cylinder/head/sector value. The culprit is that it is not guaranteed that the physical mapping is actually sequential. But the statement can be made that there is a rather high probability that a logical block n is physically adjacent to a logical block n+1. The existence of the discussed sequential layout is paramount to the I/O scheduler performing as advertised. Based on how the read anticipatory heuristic is implemented in AS, I/O environments that consist of RAID systems, operating in a hardware stripe setup, may experience rather erratic performance. This is due to the current AS implementation that is based on the notion that an I/O device has only one physical seek head, ignoring the fact that in a RAID environment, each physical disk has its own physical seek head construct. This is not recognized by the AS scheduler; therefore, the data used for the statistics analysis is getting skewed.

Further, disk drives that support TCQ perform best when they can operate on n, not 1, pending I/O requests. The read anticipatory heuristic disables TCQ. Therefore, environments that support TCQ or consist of RAID systems may benefit from either choosing an alternate I/O scheduler or setting the antic_expire parameter to 0. The tuning allows the AS scheduler to behave similarly to the deadline I/O scheduler, with the emphasis on behave and not perform.

In any computer system, among the disk drives, disk controllers, and actual memory subsystem is a hierarchy of additional controllers, host adapters, bus converters, and data paths that all impact I/O performance. In the following section, you will see how these components affect the I/O performance.