On Tue, 2017-04-11 at 12:09 -0400, Mike Snitzer wrote: > This has no place in dm-mq (or any blk-mq > driver). If it is needed it should be elevated to blk-mq core to > trigger blk_mq_delay_run_hw_queue() when BLK_MQ_RQ_QUEUE_BUSY is > returned from blk_mq_ops' .queue_rq. Hello Mike, If the blk-mq core would have to figure out whether or not a queue is no longer busy without any cooperation from the blk-mq driver all the blk-mq core could do is to attempt to rerun that queue from time to time. But at which intervals should the blk-mq core check whether or not a queue is still busy? Would it be possible to choose intervals at which to check the queue state that work well for all block drivers? Consider e.g. at the dm-mpath driver. multipath_busy() returns true as long as path initialization is in progress. Path initialization can take a long time. The (indirect) call to blk_mq_run_queue() from pg_init_done() resumes request processing immediately after path initialization has finished. Sorry but I don't think it is possible to invent an algorithm for the blk-mq core that guarantees not only that a queue is rerun as soon as it is no longer busy but also that avoids that plenty of CPU cycles are wasted by the blk-mq core for checking whether a queue is no longer busy. Bart.
