diff options
author | Paolo Valente <paolo.valente@linaro.org> | 2017-05-09 12:54:23 +0200 |
---|---|---|
committer | Jens Axboe <axboe@fb.com> | 2017-05-10 07:39:43 -0600 |
commit | 43c1b3d6e536b7b21ed329ae54280d8ba308ba92 (patch) | |
tree | f357574ada83c1a61f1a2bb7ee63164303dc6110 /block/elevator.c | |
parent | a66c38a171ed25488debf80247a9e72e1026e82c (diff) | |
download | linux-43c1b3d6e536b7b21ed329ae54280d8ba308ba92.tar.gz linux-43c1b3d6e536b7b21ed329ae54280d8ba308ba92.tar.bz2 linux-43c1b3d6e536b7b21ed329ae54280d8ba308ba92.zip |
block, bfq: stress that low_latency must be off to get max throughput
The introduction of the BFQ and Kyber I/O schedulers has triggered a
new wave of I/O benchmarks. Unfortunately, comments and discussions on
these benchmarks confirm that there is still little awareness that it
is very hard to achieve, at the same time, a low latency and a high
throughput. In particular, virtually all benchmarks measure
throughput, or throughput-related figures of merit, but, for BFQ, they
use the scheduler in its default configuration. This configuration is
geared, instead, toward a low latency. This is evidently a sign that
BFQ documentation is still too unclear on this important aspect. This
commit addresses this issue by stressing how BFQ configuration must be
(easily) changed if the only goal is maximum throughput.
Signed-off-by: Paolo Valente <paolo.valente@linaro.org>
Signed-off-by: Jens Axboe <axboe@fb.com>
Diffstat (limited to 'block/elevator.c')
0 files changed, 0 insertions, 0 deletions