Deadline Scheduler is n I/O scheduler for the Linux kernel and guarantee a start service time for a request. Deadline Scheduler imposes deadlines on all I/O operations in order to prevent wanted requests. Two deadline read and write queues (basically sorted by their deadline) are maintained. For every new request, the scheduler selects which queue will serve for it. Read queues are given high priority than write queues because during read operations the processes usually get blocked.
Now, the deadline scheduler checks if the first request in the deadline queue has expired then, a batch of requests from the sorted queue is served. The scheduler serves both a batch of requests following the chosen request in the sorted queue.
By default, the Expiration time of read request is of 500 ms and write requests of 5 seconds.
Let us understand it with a scenario :
Suppose there are three processes P1, P2 and P3 with respective deadlines. So the deadline scheduler states that if P1 makes a request at time t. It cannot make a request again at some time interval.
Deadline I/O Scheduler tunables –
When a kernel parameter can be changed during runtime is called a tunable parameter. Use sysctl command to see both static and tunable kernel parameters.
- fifo_batch (integer) :
This tunable determines the number of read or write requests to issue in a single batch, ordered in terms of increasing sector number.
- read_expire(integer) :
This tunable determines the time in milliseconds in which a read request should be serviced. Read request in I/O scheduler is assigned a deadline i.e., current time + read expire value (milliseconds).
- write_expire(integer) :
This tunable determines the time in milliseconds in which a write request should be serviced. It is the same as read_expire but for write operations.
- writes_starved(integer) :
This tunable controls the number of read batches to be processed before processing a single write batch. Higher the value of write starved, the higher the preference of read.
- front_merges(bool integer) :
A front merge is done when we fit a request in front of the queue and a back merge is opposite to the front merge. Due to the way files are typically laid out, back merge is common than the front merge. Here, the I/O scheduler merges the smaller requests into already laid out operations. If front merge tunable is set to zero, it disables the functionality of the front merge.