[dm-devel] awful request merge results while simulating high IOPS multipath

[Mike Snitzer]

On Wed, Feb 25 2015 at  6:57pm -0500,
Keith Busch <keith.busch at intel.com> wrote:

> On Wed, 25 Feb 2015, Mike Snitzer wrote:
> >On Wed, Feb 25 2015 at  1:17pm -0500,
> >Busch, Keith <keith.busch at intel.com> wrote:
> >>Our first bottleneck appears to be the device mapper's single lock
> >>request queue.
> >
> >Obviously if we switched dm-multipath over to blk-mq we'd eliminate
> >that.  I'll see how things go and will share any changes I come up
> >with.
> 
> Yes, I'm also looking at blk-mq. It appears conversion helps a lot.

Oh, so you've already started a conversion of request-based DM?

> I'm not sure though how many tags or h/w contexts to allocate to ensure
> there's enough but not too many. You can't use the underlying device's
> blk-tagset count (assuming you could even get to it) since those are
> potentially shared among many block devices.

I'm very new to the blk-mq model so I have some learning to do before
I'll be much help.

But there really won't be a one size fits all amount for those resources
will there?  A multipath device can have _a lot_ of underlying paths.