Re: [LSF/MM ATTEND][LSF/MM TOPIC] Multipath redesign

[Mike Snitzer <snitzer@redhat.com>]

On Wed, Jan 13 2016 at  5:50am -0500,
Sagi Grimberg <sagig@dev.mellanox.co.il> wrote:
 
> Another (adjacent) topic is multipath performance with blk-mq.
> 
> As I said, I've been looking at nvme multipathing support and
> initial measurements show huge contention on the multipath lock
> which really defeats the entire point of blk-mq...
> 
> I have yet to report this as my work is still in progress. I'm not sure
> if it's a topic on it's own but I'd love to talk about that as well...

This sounds like you aren't actually using blk-mq for the top-level DM
multipath queue.  And your findings contradicts what I heard from Keith
Busch when I developed request-based DM's blk-mq support, from commit 
bfebd1cdb497 ("dm: add full blk-mq support to request-based DM"):

     "Just providing a performance update. All my fio tests are getting
      roughly equal performance whether accessed through the raw block
      device or the multipath device mapper (~470k IOPS). I could only push
      ~20% of the raw iops through dm before this conversion, so this latest
      tree is looking really solid from a performance standpoint."

> >But in the end we should be able to do strip down the current (rather
> >complex) multipath-tools to just handle topology changes; everything
> >else will be done internally.
> 
> I'd love to see that happening.

Honestly, this needs to be a hardened plan that is hashed out _before_
LSF and then findings presented.  It is a complete waste of time to
debate nuance with Hannes in a one hour session.

Until I implemented the above DM core changes hch and Hannes were very
enthusiastic to throw away the existing DM multipath and multipath-tools
code (the old .request_fn queue lock bottleneck being the straw that
broke the camel's back).  Seems Hannes' enthusiasm hasn't tempered but
his hand-waving is still in full form.

Details matter.  I have no doubts aspects of what we have could be
improved but I really fail to see how moving multipathing to blk-mq is a
constructive way forward.