On Fri, Jan 15 2016 at 10:28am -0500, Benjamin Marzinski <bmarzins@xxxxxxxxxx> 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. -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
