On Mon, Jun 23, 2014 at 09:56:45AM -0400, Jeff Layton wrote: > On Mon, 23 Jun 2014 06:39:26 -0700 > Christoph Hellwig <hch@xxxxxxxxxxxxx> wrote: > > > Hi Jeff, > > > > thanks for bringing this forward. I've started looking at the series, > > but I'm a little overwhelmed as it's growing bigger and bigger with > > each posting. That also makes me a little worried about putting all > > of it into 3.17. I know you've started separating a few bits out and > > some of those actually went into 3.16, but maybe we really should > > start to some easier to split piece in first and make sure they get > > into 3.17 and then see if we can get through the rest of it in time. > > > > Thanks for taking a look. The big problem with breaking this set up is > that it will likely result in at least some performance regression in > the interim. We're adding more granular locking inside of the > coarse-grained client_mutex, which is likely to mean at least some > slowdown until the client_mutex is removed. Maybe that's worth it > though. I also don't know if the in-between state (when we have both new and old locking) is very interesting to test. > > > Besides the obvious fixes for bits that were racy before and don't > > just need better scalability one thing that strikes to mind are some > > of the higher level logic changes, like the changes fixes to various > > stateowner / stateid relations. > > > > I'll have to think about how to break those out. Unfortunately, there > are strong dependencies between some of those changes, which makes it > hard to do this in pieces. But, yes, if there's anything here it would be possible to take first that would help.... --b. -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
