[PATCH 6/6] xfs: stop using the page cache to back the buffer cache

[Dave Chinner]

On Fri, Mar 25, 2011 at 04:02:53PM -0500, Alex Elder wrote:
> On Wed, 2011-03-23 at 17:14 +1100, Dave Chinner wrote:
> > From: Dave Chinner <dchinner at redhat.com>
> > 
> > Now that the buffer cache has it's own LRU, we do not need to use
> > the page cache to provide persistent caching and reclaim
> > infrastructure. Convert the buffer cache to use alloc_pages()
> > instead of the page cache. This will remove all the overhead of page
> > cache management from setup and teardown of the buffers, as well as
> > needing to mark pages accessed as we find buffers in the buffer
> > cache.
> > 
> > By avoiding the page cache, we also remove the need to keep state in
> > the page_private(page) field for persistant storage across buffer
> > free/buffer rebuild and so all that code can be removed. This also
> > fixes the long-standing problem of not having enough bits in the
> > page_private field to track all the state needed for a 512
> > sector/64k page setup.
> > 
> > It also removes the need for page locking during reads as the pages
> > are unique to the buffer and nobody else will be attempting to
> > access them.
> > 
> > Finally, it removes the buftarg address space lock as a point of
> > global contention on workloads that allocate and free buffers
> > quickly such as when creating or removing large numbers of inodes in
> > parallel. This remove the 16TB limit on filesystem size on 32 bit
> > machines as the page index (32 bit) is no longer used for lookups
> > of metadata buffers - the buffer cache is now solely indexed by disk
> > address which is stored in a 64 bit field in the buffer.
> > 
> > Signed-off-by: Dave Chinner <dchinner at redhat.com>
> 
> This is really a great change, a long time coming.
> 
> I have two comments below, one of which I think is
> a real (but simple) problem.

Yup, i'll fix them.

> I've been using this series all week without problems.  
> This patch cleans things up so nicely I *would* like
> to include it in 2.6.39 if you can update it and turn
> it around with a pull request for me.

Ok, I'll update the series, prep a brach, run a quick sanity check
and send a pull req.
> 
> If so, I'll do some sanity testing and push it to
> oss.sgi.com, then send a pull request to Linus with
> it early next week.
> 
> Reviewed-by: Alex Elder <aelder at sgi.com>
> 
> PS  I'm sorry it took so long to get back to you on
>     this stuff.  I've had a hard time getting my brain
>     re-engaged this week after coming back from vacation
>     for some reason...

No problems, I knew you were away for a while...

Cheers,

Dave.
-- 
Dave Chinner
david at fromorbit.com