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@xxxxxxxxxx> > > > > 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@xxxxxxxxxx> > > 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@xxxxxxx> > > 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@xxxxxxxxxxxxx _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
