Il giorno 12 lug 2017, alle ore 16:22, Jens Axboe [off-list ref] ha =

scritto:

=20
On 07/12/2017 03:41 AM, Paolo Valente wrote:

quoted

=20

quoted

Il giorno 11 lug 2017, alle ore 15:58, Hou Tao [off-list ref] =

ha scritto:

quoted

quoted

=20
There are mq devices (eg., virtio-blk, nbd and loopback) which don't
invoke blk_mq_run_hw_queues() after the completion of a request.
If bfq is enabled on these devices and the slice_idle attribute or
strict_guarantees attribute is set as zero,

=20
I guess you meant slice_idle > 0 or strict_guarantees equal to 1 =

here.

quoted

=20

quoted

it is possible that
after a request completion the remaining requests of busy bfq queue
will stalled in the bfq schedule until a new request arrives.
=20
To fix the scheduler latency problem, we need to check whether or =

not

quoted

quoted

all issued requests have completed and dispatch more requests to =

driver

quoted

quoted

if there is no request in driver.
=20
Signed-off-by: Hou Tao <redacted>
=20

=20
Thanks for this fix.  My only (possible) concern is whether there
would be some more coherent and possibly more efficient solution to
this problem, outside BFQ.  For example, would it make sense to call
blk_mq_run_hw_queues(), after a request completion, from the offended
devices too?  This would make the behavior of these devices coherent
with that of the other devices.  Unfortunately I have no sound answer
to such a question.  Apart from this concern:

=20
No, that's wrong. If a scheduler decides to stop dispatching
requests before the list has been drained, it is the schedulers
responsibility to restart dispatch. Some drivers need to restart
the queue for other reasons, don't confuse the two.
=20

Thanks for clearing up this point.  As I already wrote, the patch is
then ok for me.

Thanks,
Paolo

--=20
Jens Axboe