On 07/12/2017 03:41 AM, Paolo Valente wrote: > >> Il giorno 11 lug 2017, alle ore 15:58, Hou Tao <houtao1@xxxxxxxxxx> ha scritto: >> >> 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, > > I guess you meant slice_idle > 0 or strict_guarantees equal to 1 here. > >> 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. >> >> To fix the scheduler latency problem, we need to check whether or not >> all issued requests have completed and dispatch more requests to driver >> if there is no request in driver. >> >> Signed-off-by: Hou Tao <houtao1@xxxxxxxxxx> >> > > 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: 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. -- Jens Axboe
