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