Orange Pi5 kernel

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