[dm-devel] awful request merge results while simulating high IOPS multipath
Mike Snitzer
snitzer at redhat.com
Wed Feb 25 22:10:47 UTC 2015
On Wed, Feb 25 2015 at 1:17pm -0500,
Busch, Keith <keith.busch at intel.com> wrote:
> Sorry, my reply was non sequitur to this thread. We don't do merging
> in NVMe.
NVMe may not but current dm-multipath's top-level queue will. And any
future blk-mq enabled dm-multipath (which I'm starting to look into now)
will need to also.
> 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.
FYI, here is a related exchange Jens and I had on the LSF-only mailing
list:
On Tue, Feb 24 2015 at 1:43pm -0500,
Jens Axboe <axboe at kernel.dk> wrote:
> On 02/24/2015 10:37 AM, Mike Snitzer wrote:
>
> >I agree. I'd hate to be called up front to tap dance around some yet to
> >be analyzed issue. But discussing the best way to update multipath for
> >blk-mq devices is fair game.
> >
> >As is, the current blk-mq code doesn't have any IO scheduler so the
> >overall approach that DM multipath _attempts_ to take (namely leaning on
> >the elevator to create larger requests that are then balanced across the
> >underlying paths) is a non-starter.
>
> No it isn't, blk-mq still provides merging, the logic would very
> much be the same there... I think the crux of the problem is the way
> too frequent queue runs, that'd similarly be a problem on the blk-mq
> front.
>
> --
> Jens Axboe
>
More information about the dm-devel
mailing list