Mikulas Patocka wrote: >>> What is the exact reason for your patch? I suppose that it's some >>> performance degradation caused by the fact that dm-multipath doesn't >>> distributes requests optimally across both paths. dm-multipath has >>> pluggable path selectors, so you could improve dm-round-robin.c (or write >>> alternate path selector module) and you don't have to touch generic dm >>> code to solve this problem. >>> >>> The point is that improving dm-multipath target with better path selector >>> is much less intrusive than patching device mapper core. If you improve >>> dm-multipath target, only people hacking on dm-multipath will have to >>> learn about your code. If you modify generic dm.c file, anyone doing >>> anything on device mapper must learn about your code --- so human time >>> consumed in much worse in this case. >>> >>> So, try the alternate solution (write new path selector for dm-multipath) >>> and then you can compare them and see the result --- and then it can be >>> consisdered if the high human time consumed by patching dm.c is worth the >>> performance improvement. The main purpose of request-based dm patches is to provide a framework to implement optimal path selectors in non-intrusive way. As you mentioned, it might be possible to implement a good path selector at bio-level by checking internals of underlying devices' request queues and/or I/O schedulers. However, requiring knowledge/assumptions of internals of other layer is not a right approach. Or, splitting the request-based multipath driver out of dm would trash the existing userspace tools and libraries, so that's not good either. Thus we chose the design of 'adding request-based mapping feature to dm'. It doesn't break existing target drivers and userspace tools. The feature is enabled only for request-based target drivers. If you want to add a bio-specific new feature, it's still possible. The design has been discussed in several mailing lists, Ottawa Linux Symposium and Linux Storage/Filesystem workshop including maintainers of related subsystems for these few years, and I think we got basic agreement on this direction. As for your barrier works, we are looking into the patches to make them work on request-based dm as well. Thanks, -- Jun'ichi Nomura, NEC Corporation -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
