6.4.2. Deadline I/O Scheduler
The deadline I/O scheduler attempts to provide a guaranteed latency for requests. It is important to note that the latency measurement only starts when the requests gets down to the I/O scheduler (this is an important distinction, as an application may be put to sleep waiting for request descriptors to be freed). By default, reads are given priority over writes, since applications are more likely to block on read I/O.
Deadline dispatches I/Os in batches. A batch is a sequence of either read or write I/Os which are in increasing LBA order (the one-way elevator). After processing each batch, the I/O scheduler checks to see whether write requests have been starved for too long, and then decides whether to start a new batch of reads or writes. The FIFO list of requests is only checked for expired requests at the start of each batch, and then only for the data direction of that batch. So, if a write batch is selected, and there is an expired read request, that read request will not get serviced until the write batch completes.
Tunables
fifo_batch- This determines the number of reads or writes to issue in a single batch. The default is
16. Setting this to a higher value may result in better throughput, but will also increase latency. front_merges- You can set this tunable to
0if you know your workload will never generate front merges. Unless you have measured the overhead of this check, it is advisable to leave it at its default setting (1). read_expire- This tunable allows you to set the number of milliseconds in which a read request should be serviced. By default, this is set to
500ms (half a second). write_expire- This tunable allows you to set the number of milliseconds in which a write request should be serviced. By default, this is set to
5000ms (five seconds). writes_starved- This tunable controls how many read batches can be processed before processing a single write batch. The higher this is set, the more preference is given to reads.
