> Il giorno 12 lug 2017, alle ore 16:22, Jens Axboe <axboe@xxxxxxxxx> ha scritto: > > 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. > Thanks for clearing up this point. As I already wrote, the patch is then ok for me. Thanks, Paolo > -- > Jens Axboe
