On Wed, Oct 13, 2010 at 11:30:08PM +1100, Nick Piggin wrote: > On Wed, Oct 13, 2010 at 07:25:52AM -0400, Christoph Hellwig wrote: > > On Wed, Oct 13, 2010 at 06:20:58PM +1100, Nick Piggin wrote: > > > Unfortunate timing that everybody is suddenly interested in the > > > scalability work :) > > > > People have been interested for a long time. It's just that we finally > > made forward progress to get parts of it shape for merging, which should > > have been done long time ago. > > It has been pretty close, IMO, it just needed some more reviewers, which > it only just got really. Going back a couple of weeks, it seemed as far away from inclusion as when you first posted the series - there had been no substanital review and nobody wanting to review it in it's current form. Then I'd heard you were travelling indefinitely..... There is stuff in the vfs-scale tree that is somewhat controversial and had not been discussed satisfactorily - the lock ordering (resulting in trylocks everywhere), the shrinker API change, the writeback LRU changes, the zone reclaim changes, etc - and some of them even have alternative proposals for fixing the algorithmic deficiencies. Nobody was going to review or accept that as one big lump. There's been review now because I went and did what the potential reviewers were asking for - break the series into smaller, more easily reviewable and verifiable chunks. As a result, I think we're close to the end of the review cycle for the inode_lock breakup now. I think the code is now much cleaner and more maintainable than what I originally pulled from the vfs-scale tree, and it still provides the same gains and ability to be converted to RCU algorithms in the future. Hence, IMO, the current vfs-scale tree needs to be treated as a prototype, not as a finished product. It demonstrates the the path we need to follow to move forward, as well as the gains we will get as we move in that direction, but the code in that tree is not guaranteed a free pass into the mainline tree. > etc. I had to really learn most of the code from scratch to get this far > and got quite little constructive review really until recently. Which seems to be another good reason for treating the tree as prototype code. Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
