bio-based DM multipath is back from the dead [was: Re: Notes from the four separate IO track sessions at LSF/MM]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Apr 28 2016 at 11:40am -0400,
James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> wrote:

> On Thu, 2016-04-28 at 08:11 -0400, Mike Snitzer wrote:
> > Full disclosure: I'll be looking at reinstating bio-based DM multipath to
> > regain efficiencies that now really matter when issuing IO to extremely
> > fast devices (e.g. NVMe).  bio cloning is now very cheap (due to
> > immutable biovecs), coupled with the emerging multipage biovec work that
> > will help construct larger bios, so I think it is worth pursuing to at
> > least keep our options open.

Please see the 4 topmost commits I've published here:
https://git.kernel.org/cgit/linux/kernel/git/device-mapper/linux-dm.git/log/?h=dm-4.8

All request-based DM multipath support/advances have been completly
preserved.  I've just made it so that we can now have bio-based DM
multipath too.

All of the various modes have been tested using mptest:
https://github.com/snitm/mptest

> OK, but remember the reason we moved from bio to request was partly to
> be nearer to the device but also because at that time requests were
> accumulations of bios which had to be broken out, go back up the stack
> individually and be re-elevated, which adds to the inefficiency.  In
> theory the bio splitting work will mean that we only have one or two
> split bios per request (because they were constructed from a split up
> huge bio), but when we send them back to the top to be reconstructed as
> requests there's no guarantee that the split will be correct a second
> time around and we might end up resplitting the already split bios.  If
> you do reassembly into the huge bio again before resend down the next
> queue, that's starting to look like quite a lot of work as well.

I've not even delved into the level you're laser-focused on here.
But I'm struggling to grasp why multipath is any different than any
other bio-based device...

FYI, the paper I reference in my "dm mpath: reinstate bio-based support"
commit gets into what I've always thought the real justification was for
the transition from bio-based to request-based.
--
To unsubscribe from this list: send the line "unsubscribe linux-block" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux RAID]     [Linux SCSI]     [Linux ATA RAID]     [IDE]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Device Mapper]

  Powered by Linux