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