* [LSF/MM ATTEND] plan to deprecate old .request_fn request-based code path? @ 2016-01-12 18:59 Mike Snitzer 2016-01-12 23:39 ` Mikulas Patocka 2016-01-13 11:16 ` Sagi Grimberg 0 siblings, 2 replies; 7+ messages in thread From: Mike Snitzer @ 2016-01-12 18:59 UTC (permalink / raw) To: lsf-pc; +Cc: linux-block, dm-devel 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [LSF/MM ATTEND] plan to deprecate old .request_fn request-based code path? 2016-01-12 18:59 [LSF/MM ATTEND] plan to deprecate old .request_fn request-based code path? Mike Snitzer @ 2016-01-12 23:39 ` Mikulas Patocka 2016-01-13 8:21 ` Hannes Reinecke 2016-01-13 11:16 ` Sagi Grimberg 1 sibling, 1 reply; 7+ messages in thread From: Mikulas Patocka @ 2016-01-12 23:39 UTC (permalink / raw) To: Mike Snitzer; +Cc: linux-block, dm-devel, lsf-pc 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [LSF/MM ATTEND] plan to deprecate old .request_fn request-based code path? 2016-01-12 23:39 ` Mikulas Patocka @ 2016-01-13 8:21 ` Hannes Reinecke 2016-01-13 11:02 ` Alasdair G Kergon 2016-01-15 15:28 ` Benjamin Marzinski 0 siblings, 2 replies; 7+ messages in thread From: Hannes Reinecke @ 2016-01-13 8:21 UTC (permalink / raw) To: device-mapper development, Mike Snitzer; +Cc: linux-block, lsf-pc 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) ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [LSF/MM ATTEND] plan to deprecate old .request_fn request-based code path? 2016-01-13 8:21 ` Hannes Reinecke @ 2016-01-13 11:02 ` Alasdair G Kergon 2016-01-15 15:28 ` Benjamin Marzinski 1 sibling, 0 replies; 7+ messages in thread From: Alasdair G Kergon @ 2016-01-13 11:02 UTC (permalink / raw) To: Hannes Reinecke Cc: linux-block, Junichi Nomura, device-mapper development, lsf-pc, Mike Snitzer 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [LSF/MM ATTEND] plan to deprecate old .request_fn request-based code path? 2016-01-13 8:21 ` Hannes Reinecke 2016-01-13 11:02 ` Alasdair G Kergon @ 2016-01-15 15:28 ` Benjamin Marzinski 2016-01-15 16:19 ` Mike Snitzer 1 sibling, 1 reply; 7+ messages in thread From: Benjamin Marzinski @ 2016-01-15 15:28 UTC (permalink / raw) To: device-mapper development; +Cc: linux-block, lsf-pc, Mike Snitzer 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [LSF/MM ATTEND] plan to deprecate old .request_fn request-based code path? 2016-01-15 15:28 ` Benjamin Marzinski @ 2016-01-15 16:19 ` Mike Snitzer 0 siblings, 0 replies; 7+ messages in thread From: Mike Snitzer @ 2016-01-15 16:19 UTC (permalink / raw) To: Benjamin Marzinski; +Cc: linux-block, device-mapper development, lsf-pc 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. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [LSF/MM ATTEND] plan to deprecate old .request_fn request-based code path? 2016-01-12 18:59 [LSF/MM ATTEND] plan to deprecate old .request_fn request-based code path? Mike Snitzer 2016-01-12 23:39 ` Mikulas Patocka @ 2016-01-13 11:16 ` Sagi Grimberg 1 sibling, 0 replies; 7+ messages in thread From: Sagi Grimberg @ 2016-01-13 11:16 UTC (permalink / raw) To: Mike Snitzer, lsf-pc; +Cc: linux-block, dm-devel > 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. ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2016-01-15 16:19 UTC | newest] Thread overview: 7+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2016-01-12 18:59 [LSF/MM ATTEND] plan to deprecate old .request_fn request-based code path? Mike Snitzer 2016-01-12 23:39 ` Mikulas Patocka 2016-01-13 8:21 ` Hannes Reinecke 2016-01-13 11:02 ` Alasdair G Kergon 2016-01-15 15:28 ` Benjamin Marzinski 2016-01-15 16:19 ` Mike Snitzer 2016-01-13 11:16 ` Sagi Grimberg
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.