block, bfq: prevent soft_rt_next_start from being stuck at infinity
authorDavide Sapienza <sapienza.dav@gmail.com>
Thu, 31 May 2018 14:45:08 +0000 (16:45 +0200)
committerJens Axboe <axboe@kernel.dk>
Thu, 31 May 2018 14:54:41 +0000 (08:54 -0600)
commitf6c3ca0e58446e8de6c6f1a2a73f037fb900c372
tree4bb57aa40714ad8cdeff7eebe0ecd26a08d13662
parentd450542e3ce0efd030316b7846cc7231300b2bc9
block, bfq: prevent soft_rt_next_start from being stuck at infinity

BFQ can deem a bfq_queue as soft real-time only if the queue
- periodically becomes completely idle, i.e., empty and with
  no still-outstanding I/O request;
- after becoming idle, gets new I/O only after a special reference
  time soft_rt_next_start.

In this respect, after commit "block, bfq: consider also past I/O in
soft real-time detection", the value of soft_rt_next_start can never
decrease. This causes a problem with the following special updating
case for soft_rt_next_start: to prevent queues that are not completely
idle to be wrongly detected as soft real-time (when they become
non-empty again), soft_rt_next_start is temporarily set to infinity
for empty queues with still outstanding I/O requests. But, if such an
update is actually performed, then, because of the above commit,
soft_rt_next_start will be stuck at infinity forever, and the queue
will have no more chance to be considered soft real-time.

On slow systems, this problem does cause actual soft real-time
applications to be occasionally not detected as such.

This commit addresses this issue by eliminating the pushing of
soft_rt_next_start to infinity, and by changing the way non-empty
queues are prevented from being wrongly detected as soft
real-time. Simply, a queue that becomes non-empty again can now be
detected as soft real-time only if it has no outstanding I/O request.

Signed-off-by: Davide Sapienza <sapienza.dav@gmail.com>
Signed-off-by: Paolo Valente <paolo.valente@linaro.org>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
block/bfq-iosched.c