Donate to e Foundation | Murena handsets with /e/OS | Own a part of Murena! Learn more

Commit 233f0bf4 authored by Paolo Valente's avatar Paolo Valente Committed by Jens Axboe
Browse files

doc, block, bfq: fix some typos and remove stale stuff 



In addition to containing some typos and stale sentences, the file
bfq-iosched.txt still mentioned a set of sysfs parameters that have
been removed from this version of bfq. This commit fixes all these
issues.

Signed-off-by: default avatarPaolo Valente <paolo.valente@linaro.org>
Reviewed-by: default avatarJeremy Hickman <jeremywh7@gmail.com>
Reviewed-by: default avatarLaurentiu Nicola <lnicola@dend.ro>
Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
parent 43cade80

Documentation/block/bfq-iosched.txt

+10 −56
Original line number Original line Diff line number Diff line
@@ -16,14 +16,16 @@ throughput. So, when needed for achieving a lower latency, BFQ builds 
schedules that may lead to a lower throughput. If your main or only

schedules that may lead to a lower throughput. If your main or only

goal, for a given device, is to achieve the maximum-possible

goal, for a given device, is to achieve the maximum-possible

throughput at all times, then do switch off all low-latency heuristics

throughput at all times, then do switch off all low-latency heuristics

for that device, by setting low_latency to 0. Full details in Section 3.

for that device, by setting low_latency to 0. See Section 3 for

details on how to configure BFQ for the desired tradeoff between

latency and throughput, or on how to maximize throughput.





On average CPUs, the current version of BFQ can handle devices

On average CPUs, the current version of BFQ can handle devices

performing at most ~30K IOPS; at most ~50 KIOPS on faster CPUs. As a

performing at most ~30K IOPS; at most ~50 KIOPS on faster CPUs. As a

reference, 30-50 KIOPS correspond to very high bandwidths with

reference, 30-50 KIOPS correspond to very high bandwidths with

sequential I/O (e.g., 8-12 GB/s if I/O requests are 256 KB large), and

sequential I/O (e.g., 8-12 GB/s if I/O requests are 256 KB large), and

to 120-200 MB/s with 4KB random I/O. BFQ has not yet been tested on

to 120-200 MB/s with 4KB random I/O. BFQ is currently being tested on

multi-queue devices.

multi-queue devices too.





The table of contents follow. Impatients can just jump to Section 3.

The table of contents follow. Impatients can just jump to Section 3.
@@ -154,10 +156,10 @@ plus a lot of code, are borrowed from CFQ. 




      - With respect to idling for service guarantees, if several

      - With respect to idling for service guarantees, if several

	processes are competing for the device at the same time, but

	processes are competing for the device at the same time, but

	all processes (and groups, after the following commit) have

	all processes and groups have the same weight, then BFQ

	the same weight, then BFQ guarantees the expected throughput

	guarantees the expected throughput distribution without ever

	distribution without ever idling the device. Throughput is

	idling the device. Throughput is thus as high as possible in

	thus as high as possible in this common scenario.

	this common scenario.





  - If low-latency mode is enabled (default configuration), BFQ

  - If low-latency mode is enabled (default configuration), BFQ

    executes some special heuristics to detect interactive and soft

    executes some special heuristics to detect interactive and soft
@@ -191,10 +193,7 @@ plus a lot of code, are borrowed from CFQ. 
  - Queues are scheduled according to a variant of WF2Q+, named

  - Queues are scheduled according to a variant of WF2Q+, named

    B-WF2Q+, and implemented using an augmented rb-tree to preserve an

    B-WF2Q+, and implemented using an augmented rb-tree to preserve an

    O(log N) overall complexity.  See [2] for more details. B-WF2Q+ is

    O(log N) overall complexity.  See [2] for more details. B-WF2Q+ is

    also ready for hierarchical scheduling. However, for a cleaner

    also ready for hierarchical scheduling, details in Section 4.

    logical breakdown, the code that enables and completes

    hierarchical support is provided in the next commit, which focuses

    exactly on this feature.





  - B-WF2Q+ guarantees a tight deviation with respect to an ideal,

  - B-WF2Q+ guarantees a tight deviation with respect to an ideal,

    perfectly fair, and smooth service. In particular, B-WF2Q+

    perfectly fair, and smooth service. In particular, B-WF2Q+
@@ -427,51 +426,6 @@ Read-only parameter, used to show the weights of the currently active 
BFQ queues.

BFQ queues.









wr_ tunables

------------



BFQ exports a few parameters to control/tune the behavior of

low-latency heuristics.



wr_coeff



Factor by which the weight of a weight-raised queue is multiplied. If

the queue is deemed soft real-time, then the weight is further

multiplied by an additional, constant factor.



wr_max_time



Maximum duration of a weight-raising period for an interactive task

(ms). If set to zero (default value), then this value is computed

automatically, as a function of the peak rate of the device. In any

case, when the value of this parameter is read, it always reports the

current duration, regardless of whether it has been set manually or

computed automatically.



wr_max_softrt_rate



Maximum service rate below which a queue is deemed to be associated

with a soft real-time application, and is then weight-raised

accordingly (sectors/sec).



wr_min_idle_time



Minimum idle period after which interactive weight-raising may be

reactivated for a queue (in ms).



wr_rt_max_time



Maximum weight-raising duration for soft real-time queues (in ms). The

start time from which this duration is considered is automatically

moved forward if the queue is detected to be still soft real-time

before the current soft real-time weight-raising period finishes.



wr_min_inter_arr_async



Minimum period between I/O request arrivals after which weight-raising

may be reactivated for an already busy async queue (in ms).





4. Group scheduling with BFQ

4. Group scheduling with BFQ

============================

============================