p71924506
/
linux_old1
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

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: Paolo Valente <paolo.valente@linaro.org>
Reviewed-by: Jeremy Hickman <jeremywh7@gmail.com>
Reviewed-by: Laurentiu Nicola <lnicola@dend.ro>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
This commit is contained in:
Paolo Valente 2017-08-31 20:00:30 +02:00 committed by Jens Axboe
parent 43cade803e
commit 233f0bf415
1 changed files with 10 additions and 56 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

66
Documentation/block/bfq-iosched.txt
View File

@ -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
============================ ============================