On Fri, 10 Apr 2009, Mike Snitzer wrote: > Hi Mikulaus, > > Figured I'd give you this heads up on the request-based multipath > patches too considering your recent "bottom-layer barrier support" > patchset (where you said multipath support is coming later). > > We likely want to coordinate with the NEC guys so as to make sure things > are in order for the request-based patches to get merged along with your > remaining barrier work for 2.6.31. > > Mike > > p.s. below you can see I mistakenly said to Kiyoshi that the recent > barrier patches that got merged upstream were "the last of the DM > barrier support"... Hi I would say one thing about the request-based patches --- don't do this. Your patch adds an alternate I/O path to request processing on device mapper. So, with your patch, there will be two I/O request paths. It means that any work on generic device-mapper code that will have to be done in the future (such as for example barriers that I did) will be twice harder. It will take twice the time to understand request processing, twice brain capacity to remember it, twice the time for coding, twice the time for code review, twice the time for testing. If the patch goes in, it will make a lot of things twice harder. And once the patch is in productive kernels, there'd be very little possibility to pull it out. 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. Mikulas > On Fri, Apr 10 2009 at 11:19am -0400, > Mike Snitzer <snitzer@xxxxxxxxxx> wrote: > > > FYI > > > > ----- Forwarded message from Kiyoshi Ueda <k-ueda@xxxxxxxxxxxxx> ----- > > > > > From: Kiyoshi Ueda <k-ueda@xxxxxxxxxxxxx> > > > Date: Fri, 10 Apr 2009 15:08:06 +0900 > > > To: Mike Snitzer <snitzer@xxxxxxxxxx> > > > CC: Jun'ichi Nomura <j-nomura@xxxxxxxxxxxxx> > > > Subject: Re: request-based dm-multipath > > > > > > Hi Mike, > > > > > > > > > > > Hi Kiyoshi, > > > > > > > > I just wanted to follow-up with you to understand if you'll be posting > > > > the request-based patches rebased against 2.6.30-rcX. Please note that > > > > Alasdair just requested Linus pull the last of the DM barrier support > > > > into what will be 2.6.30-rc2. > > > > > > Yes. > > > Current request-based patch does't have barrier support. > > > So I think I have to implement barrier support to post the next update. > > > > > > > I'd imagine you'd like the merging of the request-based and dynamic load > > > > balancer patches to be a priority for 2.6.31? > > > > > > Yes. That's right. > > > > > > Thanks, > > > Kiyoshi Ueda > > > > ----- End forwarded message ----- > -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
