Re: [PATCH 17/18] fs: icache remove inode_lock

[Dave Chinner <david@fromorbit.com>]

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@fromorbit.com