summaryrefslogtreecommitdiffstats
path: root/block
diff options
context:
space:
mode:
authorPaolo Valente <paolo.valente@linaro.org>2017-05-09 12:54:23 +0200
committerJens Axboe <axboe@fb.com>2017-05-10 07:39:43 -0600
commit43c1b3d6e536b7b21ed329ae54280d8ba308ba92 (patch)
treef357574ada83c1a61f1a2bb7ee63164303dc6110 /block
parenta66c38a171ed25488debf80247a9e72e1026e82c (diff)
downloadop-kernel-dev-43c1b3d6e536b7b21ed329ae54280d8ba308ba92.zip
op-kernel-dev-43c1b3d6e536b7b21ed329ae54280d8ba308ba92.tar.gz
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')
-rw-r--r--block/bfq-iosched.c5
1 files changed, 5 insertions, 0 deletions
diff --git a/block/bfq-iosched.c b/block/bfq-iosched.c
index bd8499e..08ce450 100644
--- a/block/bfq-iosched.c
+++ b/block/bfq-iosched.c
@@ -56,6 +56,11 @@
* rotational or flash-based devices, and to get the job done quickly
* for applications consisting in many I/O-bound processes.
*
+ * NOTE: if the main or only goal, with a given device, is to achieve
+ * the maximum-possible throughput at all times, then do switch off
+ * all low-latency heuristics for that device, by setting low_latency
+ * to 0.
+ *
* BFQ is described in [1], where also a reference to the initial, more
* theoretical paper on BFQ can be found. The interested reader can find
* in the latter paper full details on the main algorithm, as well as
OpenPOWER on IntegriCloud