blob: be08ffd1e9b82a52504c05ad657ebb4bd895d80b [file] [log] [blame]
Linus Torvalds1da177e2005-04-16 15:20:36 -07001Deadline 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
8Each io queue has a set of io scheduler tunables associated with it. These
9tunables control how the io scheduler works. You can find these entries
10in:
11
12/sys/block/<device>/queue/iosched
13
14assuming that you have sysfs mounted on /sys. If you don't have sysfs mounted,
15you can do so by typing:
16
17# mount none /sys -t sysfs
18
19
20********************************************************************************
21
22
23read_expire (in ms)
24-----------
25
Matt LaPlantea2ffd272006-10-03 22:49:15 +020026The goal of the deadline io scheduler is to attempt to guarantee a start
Linus Torvalds1da177e2005-04-16 15:20:36 -070027service time for a request. As we focus mainly on read latencies, this is
28tunable. When a read request first enters the io scheduler, it is assigned
29a deadline that is the current time + the read_expire value in units of
Matt LaPlante2fe0ae72006-10-03 22:50:39 +020030milliseconds.
Linus Torvalds1da177e2005-04-16 15:20:36 -070031
32
33write_expire (in ms)
34-----------
35
36Similar to read_expire mentioned above, but for writes.
37
38
39fifo_batch
40----------
41
42When a read request expires its deadline, we must move some requests from
43the sorted io scheduler list to the block device dispatch queue. fifo_batch
44controls how many requests we move, based on the cost of each request. A
45request is either qualified as a seek or a stream. The io scheduler knows
46the last request that was serviced by the drive (or will be serviced right
47before this one). See seek_cost and stream_unit.
48
49
50write_starved (number of dispatches)
51-------------
52
53When we have to move requests from the io scheduler queue to the block
54device dispatch queue, we always give a preference to reads. However, we
55don't want to starve writes indefinitely either. So writes_starved controls
56how many times we give preference to reads over writes. When that has been
57done writes_starved number of times, we dispatch some writes based on the
58same criteria as reads.
59
60
61front_merges (bool)
62------------
63
64Sometimes it happens that a request enters the io scheduler that is contigious
65with a request that is already on the queue. Either it fits in the back of that
66request, or it fits at the front. That is called either a back merge candidate
67or a front merge candidate. Due to the way files are typically laid out,
68back merges are much more common than front merges. For some work loads, you
69may even know that it is a waste of time to spend any time attempting to
70front merge requests. Setting front_merges to 0 disables this functionality.
71Front merges may still occur due to the cached last_merge hint, but since
72that comes at basically 0 cost we leave that on. We simply disable the
73rbtree front sector lookup when the io scheduler merge function is called.
74
75
76Nov 11 2002, Jens Axboe <axboe@suse.de>
77
78