[LSF/MM ATTEND] plan to deprecate old .request_fn request-based code path?

[LSF/MM ATTEND] plan to deprecate old .request_fn request-based code path?

[Mike Snitzer]

Hi,

I'd like to attend LSF/MM and as the subject covers I'd like to at least
participate in a discussion about plans (realistic or not) for
removing/deprecating the old .request_fn path in block core and block
drivers.

The request-based DM code (only used for multipath) has gotten more
complex to support both old .request_fn and blk-mq (and stacking
combinations: .request_fn ontop of blk-mq paths, blk-mq ontop of
.request_fn paths).  Simplifying DM core in this area would be nice.

One of the hurdles has been blk-mq doesn't yet have a scheduler.  I know
Jens had/has something in the works.  But there is also the question of
whether DM's top-level blk-mq request_queue should be trained to
leverage/stack underlying blk-mq request_queue capabilities (Keith Busch
was going to look at this aspect in the context of multipath on NVMe but
I never heard anything from Keith on that).  As of now DM multipath's
blk-mq request_queue only supports a single (virtual) hw queue.

In addition to the above topic, I'd be open to discussing Linux MD
maintainership options with others if for some reason that is still an
unresolved situation come mid April.

Thanks,
Mike

Re: [LSF/MM ATTEND] plan to deprecate old .request_fn request-based code path?

[Mikulas Patocka]

On Tue, 12 Jan 2016, Mike Snitzer wrote:

> Hi,
> 
> I'd like to attend LSF/MM and as the subject covers I'd like to at least
> participate in a discussion about plans (realistic or not) for
> removing/deprecating the old .request_fn path in block core and block
> drivers.
> 
> The request-based DM code (only used for multipath) has gotten more
> complex to support both old .request_fn and blk-mq (and stacking
> combinations: .request_fn ontop of blk-mq paths, blk-mq ontop of
> .request_fn paths).  Simplifying DM core in this area would be nice.
> 
> One of the hurdles has been blk-mq doesn't yet have a scheduler.  I know
> Jens had/has something in the works.  But there is also the question of
> whether DM's top-level blk-mq request_queue should be trained to
> leverage/stack underlying blk-mq request_queue capabilities (Keith Busch
> was going to look at this aspect in the context of multipath on NVMe but
> I never heard anything from Keith on that).  As of now DM multipath's
> blk-mq request_queue only supports a single (virtual) hw queue.
> 
> In addition to the above topic, I'd be open to discussing Linux MD
> maintainership options with others if for some reason that is still an
> unresolved situation come mid April.
> 
> Thanks,
> Mike

Convert multipath from request-based to bio-based and these problems in 
device mapper core will disappear :-)

Mikulas

Re: [LSF/MM ATTEND] plan to deprecate old .request_fn request-based code path?

[Hannes Reinecke]

On 01/13/2016 12:39 AM, Mikulas Patocka wrote:
>
>
> On Tue, 12 Jan 2016, Mike Snitzer wrote:
>
>> Hi,
>>
>> I'd like to attend LSF/MM and as the subject covers I'd like to at least
>> participate in a discussion about plans (realistic or not) for
>> removing/deprecating the old .request_fn path in block core and block
>> drivers.
>>
>> The request-based DM code (only used for multipath) has gotten more
>> complex to support both old .request_fn and blk-mq (and stacking
>> combinations: .request_fn ontop of blk-mq paths, blk-mq ontop of
>> .request_fn paths).  Simplifying DM core in this area would be nice.
>>
>> One of the hurdles has been blk-mq doesn't yet have a scheduler.  I know
>> Jens had/has something in the works.  But there is also the question of
>> whether DM's top-level blk-mq request_queue should be trained to
>> leverage/stack underlying blk-mq request_queue capabilities (Keith Busch
>> was going to look at this aspect in the context of multipath on NVMe but
>> I never heard anything from Keith on that).  As of now DM multipath's
>> blk-mq request_queue only supports a single (virtual) hw queue.
>>
>> In addition to the above topic, I'd be open to discussing Linux MD
>> maintainership options with others if for some reason that is still an
>> unresolved situation come mid April.
>>
>> Thanks,
>> Mike
>
> Convert multipath from request-based to bio-based and these problems in
> device mapper core will disappear :-)
>
We have been down that road already. It doesn't work.
There is a reason why we switched to request-based multipathing.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		   Teamlead Storage & Networking
hare@suse.de			               +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)

Re: [LSF/MM ATTEND] plan to deprecate old .request_fn request-based code path?

[Alasdair G Kergon]

On Wed, Jan 13, 2016 at 09:21:24AM +0100, Hannes Reinecke wrote:
> We have been down that road already. It doesn't work.
> There is a reason why we switched to request-based multipathing.

It's worth reminding people of the original write-up explaining this
switch:

  https://www.kernel.org/doc/ols/2007/ols2007v2-pages-235-244.pdf

(and that since that was written, there have been plenty of changes,
both to the request-based code itself and the bio-based path which Kent
streamlined).

Alasdair

Re: [LSF/MM ATTEND] plan to deprecate old .request_fn request-based code path?

[Sagi Grimberg]

> Hi,
>
> I'd like to attend LSF/MM and as the subject covers I'd like to at least
> participate in a discussion about plans (realistic or not) for
> removing/deprecating the old .request_fn path in block core and block
> drivers.
>
> The request-based DM code (only used for multipath) has gotten more
> complex to support both old .request_fn and blk-mq (and stacking
> combinations: .request_fn ontop of blk-mq paths, blk-mq ontop of
> .request_fn paths).  Simplifying DM core in this area would be nice.
>
> One of the hurdles has been blk-mq doesn't yet have a scheduler.  I know
> Jens had/has something in the works.  But there is also the question of
> whether DM's top-level blk-mq request_queue should be trained to
> leverage/stack underlying blk-mq request_queue capabilities (Keith Busch
> was going to look at this aspect in the context of multipath on NVMe but
> I never heard anything from Keith on that).  As of now DM multipath's
> blk-mq request_queue only supports a single (virtual) hw queue.

I strongly agree we can do better here. Initial measurements of
request-based DM multipath over the (soon to come) nvme-loop driver
shows improvement from the bio-based code, but instrumentation reveals
we have plenty of room for improvement.

Re: [LSF/MM ATTEND] plan to deprecate old .request_fn request-based code path?

[Benjamin Marzinski]

On Wed, Jan 13, 2016 at 09:21:24AM +0100, Hannes Reinecke wrote:
> On 01/13/2016 12:39 AM, Mikulas Patocka wrote:
> >
> >
> >On Tue, 12 Jan 2016, Mike Snitzer wrote:
> >
> >>Hi,
> >>
> >>I'd like to attend LSF/MM and as the subject covers I'd like to at least
> >>participate in a discussion about plans (realistic or not) for
> >>removing/deprecating the old .request_fn path in block core and block
> >>drivers.
> >>
> >>The request-based DM code (only used for multipath) has gotten more
> >>complex to support both old .request_fn and blk-mq (and stacking
> >>combinations: .request_fn ontop of blk-mq paths, blk-mq ontop of
> >>.request_fn paths).  Simplifying DM core in this area would be nice.
> >>
> >>One of the hurdles has been blk-mq doesn't yet have a scheduler.  I know
> >>Jens had/has something in the works.  But there is also the question of
> >>whether DM's top-level blk-mq request_queue should be trained to
> >>leverage/stack underlying blk-mq request_queue capabilities (Keith Busch
> >>was going to look at this aspect in the context of multipath on NVMe but
> >>I never heard anything from Keith on that).  As of now DM multipath's
> >>blk-mq request_queue only supports a single (virtual) hw queue.
> >>
> >>In addition to the above topic, I'd be open to discussing Linux MD
> >>maintainership options with others if for some reason that is still an
> >>unresolved situation come mid April.
> >>
> >>Thanks,
> >>Mike
> >
> >Convert multipath from request-based to bio-based and these problems in
> >device mapper core will disappear :-)
> >
> We have been down that road already. It doesn't work.
> There is a reason why we switched to request-based multipathing.

I have been wondering lately if devices that don't benefit from
reordering or lots of time spent coalescing requests would do better (or
at least equally well) if we we brought back the option of bio based
multipathing.  However, I still think that for devices where reordering
and coalescing provides a significant performance boost, there will be
improvements by using request based multipath.  So unfortunately, this
would mean supporting both, which is adding instead of removing
complexity.  But we would then we would be in better shape if/when we
eventually do decide to deprecate request-based dm.

Also, I think we could improve on round-robin as a path selector to try
and get adjacent IOs going down the same path.

-Ben
 
> Cheers,
> 
> Hannes
> -- 
> Dr. Hannes Reinecke		   Teamlead Storage & Networking
> hare@suse.de			               +49 911 74053 688
> SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
> GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
> HRB 21284 (AG Nürnberg)
> 
> --
> dm-devel mailing list
> dm-devel@redhat.com
> https://www.redhat.com/mailman/listinfo/dm-devel

Re: [LSF/MM ATTEND] plan to deprecate old .request_fn request-based code path?

[Mike Snitzer]

On Fri, Jan 15 2016 at 10:28am -0500,
Benjamin Marzinski <bmarzins@redhat.com> wrote:

> On Wed, Jan 13, 2016 at 09:21:24AM +0100, Hannes Reinecke wrote:
> > On 01/13/2016 12:39 AM, Mikulas Patocka wrote:
> > >
> > >
> > >On Tue, 12 Jan 2016, Mike Snitzer wrote:
> > >
> > >>Hi,
> > >>
> > >>I'd like to attend LSF/MM and as the subject covers I'd like to at least
> > >>participate in a discussion about plans (realistic or not) for
> > >>removing/deprecating the old .request_fn path in block core and block
> > >>drivers.
> > >>
> > >>The request-based DM code (only used for multipath) has gotten more
> > >>complex to support both old .request_fn and blk-mq (and stacking
> > >>combinations: .request_fn ontop of blk-mq paths, blk-mq ontop of
> > >>.request_fn paths).  Simplifying DM core in this area would be nice.
> > >>
> > >>One of the hurdles has been blk-mq doesn't yet have a scheduler.  I know
> > >>Jens had/has something in the works.  But there is also the question of
> > >>whether DM's top-level blk-mq request_queue should be trained to
> > >>leverage/stack underlying blk-mq request_queue capabilities (Keith Busch
> > >>was going to look at this aspect in the context of multipath on NVMe but
> > >>I never heard anything from Keith on that).  As of now DM multipath's
> > >>blk-mq request_queue only supports a single (virtual) hw queue.
> > >>
> > >>In addition to the above topic, I'd be open to discussing Linux MD
> > >>maintainership options with others if for some reason that is still an
> > >>unresolved situation come mid April.
> > >>
> > >>Thanks,
> > >>Mike
> > >
> > >Convert multipath from request-based to bio-based and these problems in
> > >device mapper core will disappear :-)
> > >
> > We have been down that road already. It doesn't work.
> > There is a reason why we switched to request-based multipathing.
> 
> I have been wondering lately if devices that don't benefit from
> reordering or lots of time spent coalescing requests would do better (or
> at least equally well) if we we brought back the option of bio based
> multipathing.  However, I still think that for devices where reordering
> and coalescing provides a significant performance boost, there will be
> improvements by using request based multipath.  So unfortunately, this
> would mean supporting both, which is adding instead of removing
> complexity.  But we would then we would be in better shape if/when we
> eventually do decide to deprecate request-based dm.
> 
> Also, I think we could improve on round-robin as a path selector to try
> and get adjacent IOs going down the same path.

Even fast storage benefits from deadline or noop schedulers.

I'm not eager to prop up a bio-based DM multipath target.. I think it
best to put more energy to optimizing the exisiting request-based DM
blk-mq support before we seriously consider punting back to bio-based.