Re: blk-mq request allocation stalls [was: Re: [PATCH v3 0/8] dm: add request-based blk-mq support]

[Mike Snitzer <snitzer@redhat.com>]

On Wed, Jan 07 2015 at 12:35pm -0500,
Jens Axboe <axboe@kernel.dk> 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.