• Home
  • Raw
  • Download

Lines Matching +full:back +full:- +full:to +full:- +full:back

5 This little file attempts to document how the deadline io scheduler works.
7 of interest to power users.
10 -----------------------
11 Refer to Documentation/block/switching-sched.rst for information on
12 selecting an io scheduler on a per-device basis.
14 ------------------------------------------------------------------------------
17 -----------------------
19 The goal of the deadline io scheduler is to attempt to guarantee a start
27 -----------------------
29 Similar to read_expire mentioned above, but for writes.
33 ------------------------------------
36 write) which are serviced in increasing sector order. To limit extra seeking,
40 This parameter tunes the balance between per-request latency and aggregate
42 a value of 1 yields first-come first-served behaviour). Increasing fifo_batch
47 --------------------------------------
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
58 ----------------------
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