diff options
author | Paolo Valente <paolo.valente@linaro.org> | 2019-01-29 12:06:31 +0100 |
---|---|---|
committer | Jens Axboe <axboe@kernel.dk> | 2019-01-31 12:50:23 -0700 |
commit | ac8b0cb415f3aa9162009d39624501d37031533b (patch) | |
tree | 7535aac3227f576c0625be34b15d1bbcedeb9d31 /usr | |
parent | 05c2f5c30b3ca2346a5bb7c74b0c9515d8f4fbd2 (diff) | |
download | linux-ac8b0cb415f3aa9162009d39624501d37031533b.tar.gz linux-ac8b0cb415f3aa9162009d39624501d37031533b.tar.bz2 linux-ac8b0cb415f3aa9162009d39624501d37031533b.zip |
block, bfq: do not plug I/O of in-service queue when harmful
If the in-service bfq_queue is sync and remains temporarily idle, then
I/O dispatching (from other queues) may be plugged. It may be dome for
two reasons: either to boost throughput, or to preserve the bandwidth
share of the in-service queue. In the first case, if the I/O of the
in-service queue, when it finally arrives, consists only of one small
I/O request, then it makes sense to plug even the I/O of the in-service
queue. In fact, serving such a small request immediately is likely to
lower throughput instead of boosting it, whereas waiting a little bit is
likely to let that request grow, thanks to request merging, and become
more profitable in terms of throughput (this is likely to happen exactly
because the I/O of the queue has been detected to boost throughput).
On the opposite end, if I/O dispatching is being plugged only to
preserve the bandwidth of the in-service queue, then it would be better
not to plug also the I/O of the in-service queue, because such a
plugging is likely to cause only loss of bandwidth for the queue.
Unfortunately, no distinction is made between the two cases, and the I/O
of the in-service queue is always plugged in case just a small I/O
request arrives. This commit draws this missing distinction and does not
perform harmful plugging.
Signed-off-by: Paolo Valente <paolo.valente@linaro.org>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Diffstat (limited to 'usr')
0 files changed, 0 insertions, 0 deletions