1Deadline IO scheduler tunables 2============================== 3 4This little file attempts to document how the deadline io scheduler works. 5In particular, it will clarify the meaning of the exposed tunables that may be 6of interest to power users. 7 8Selecting IO schedulers 9----------------------- 10Refer to Documentation/block/switching-sched.txt for information on 11selecting an io scheduler on a per-device basis. 12 13 14******************************************************************************** 15 16 17read_expire (in ms) 18----------- 19 20The goal of the deadline io scheduler is to attempt to guarantee a start 21service time for a request. As we focus mainly on read latencies, this is 22tunable. When a read request first enters the io scheduler, it is assigned 23a deadline that is the current time + the read_expire value in units of 24milliseconds. 25 26 27write_expire (in ms) 28----------- 29 30Similar to read_expire mentioned above, but for writes. 31 32 33fifo_batch (number of requests) 34---------- 35 36Requests are grouped into ``batches'' of a particular data direction (read or 37write) which are serviced in increasing sector order. To limit extra seeking, 38deadline expiries are only checked between batches. fifo_batch controls the 39maximum number of requests per batch. 40 41This parameter tunes the balance between per-request latency and aggregate 42throughput. When low latency is the primary concern, smaller is better (where 43a value of 1 yields first-come first-served behaviour). Increasing fifo_batch 44generally improves throughput, at the cost of latency variation. 45 46 47writes_starved (number of dispatches) 48-------------- 49 50When we have to move requests from the io scheduler queue to the block 51device dispatch queue, we always give a preference to reads. However, we 52don't want to starve writes indefinitely either. So writes_starved controls 53how many times we give preference to reads over writes. When that has been 54done writes_starved number of times, we dispatch some writes based on the 55same criteria as reads. 56 57 58front_merges (bool) 59------------ 60 61Sometimes it happens that a request enters the io scheduler that is contiguous 62with a request that is already on the queue. Either it fits in the back of that 63request, or it fits at the front. That is called either a back merge candidate 64or a front merge candidate. Due to the way files are typically laid out, 65back merges are much more common than front merges. For some work loads, you 66may even know that it is a waste of time to spend any time attempting to 67front merge requests. Setting front_merges to 0 disables this functionality. 68Front merges may still occur due to the cached last_merge hint, but since 69that comes at basically 0 cost we leave that on. We simply disable the 70rbtree front sector lookup when the io scheduler merge function is called. 71 72 73Nov 11 2002, Jens Axboe <jens.axboe@oracle.com> 74 75 76