On Fri, Jan 25, 2002 at 08:53:28AM -0800, Jason R Thorpe wrote:
> On Fri, Jan 25, 2002 at 12:12:57AM -0500, Perry E. Metzger wrote:
> 
>  > Well, the need is that it would be good for us to be able to do two
>  > find(1)s of a large tree and have the disk only spin on the first
>  > one. If you have the RAM, it is far less costly to cache all that
>  > data. This is of great practical importance at times for performance.
> 
> So, while I agree this would be nice, stop to consider that if you
> also plop file metadata into the page cache:
> 
> 	(1) You now have 3 policy knobs to futz with when picking
> 	    a page to evict: anon, file data, filesystem metadata.

actually we already distinguish 3 types of pages:
anon, file data, executable data.  if we were to distinguish
metadata from file data, that would be 4.


> 	(2) You have to decide where the metadata pages will live,
> 	    i.e. which VM object they'll be associated with.  For
> 	    directories, this is mostly easy, since directories
> 	    have vnodes.  But for other types of metadata (inodes,
> 	    superblocks, cylinder groups, etc.), you have to pick
> 	    another vnode to associate them with.  That would probably
> 	    be the vnode for the underlying device.

putting metadata other than directories and symlinks in the page cache
is problematic because those other types of metadata probably aren't
page-aligned in device offset and size, so storing that as pages off
the block device vnode could cause aliasing.

the other type of filesystem metadata (indirect blocks) is also more
difficult to move to the page cache, because the current design might
need to read an indirect block to write a page, so if we needed to allocate
a page to hold the indirect block in memory, that could deadlock.

so it would probably only be worthwhile to move directories and symlinks
to the page cache, but moving those two would be useful.

-Chuck


> 	(3) To make (2) work, you probably have to UBC'ify all block
> 	    device access.