On Wed, Jan 07 2015 at 12:35pm -0500, Jens Axboe <axboe@xxxxxxxxx> wrote: > On 01/07/2015 10:18 AM, Mike Snitzer wrote: > > > >Looking closer, why not have blk_run_queue() (and blk_run_queue_async) > >call blk_mq_start_stopped_hw_queues() if q->mq_ops? As is > >scsi_run_queue() open-codes it. > > > >Actually, that is likely the ultimate problem: blk_run_queue* aren't > >trained for q->mq_ops. As such DM would need to open code a call to > >blk_mq_start_stopped_hw_queues. Turns out that concern was bogus (as was the patch I shared), request-based DM's request_queue isn't using blk-mq even if the underlying devices are. I'm not sure what is causing Bart's slow down; I cannot reproduce any hang using a 100MB scsi_debug (ramdisk) device on the host that is exported over virtio-blk into a guest that then layers a multipath device on the blk-mq virtio-blk device. > It's not completely parallel how SCSI uses it. blk_run_queue(), for > legacy request_fn, does not start stopped queues. For the mq path, > scsi-mq decided to do that. So if we embed > blk_mq_start_stopped_hw_queues() in blk_run_queue*(), then we'd have > different behavior between mq and non-mq. We could have > blk_start_queue() do the right thing, but that would require > different contexts between mq and non-mq, as non-mq requires that to > be called with the queue lock held and ints disabled. New wrappers could be introduced and drivers converted to use them but best to just leave well enough alone. -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
