Re: [NFS] Re: [PATCH][RFC] NFS: Improving the access cache

[Neil Brown <neilb@suse.de>]

On Sunday May 7, cel@citi.umich.edu wrote:
> > If you have one particular file that is used regularly - and so never
> > falls out of cache - and is used occasionally by every single user in
> > your system, then that one inode could contribute to thousands of
> > access cache items that will never be purged.
> 
> I speculate that this would not be a problem.
> 
> First, each entry in the cache is not going to be very large.  For the 
> sake of easy math, let's say each one is 32 bytes.  One hundred thousand 
> of these is a little more than 3MB.  Or, say we have ten thousand files 
> with 10 different access cache entries: again, that's just about 3MB. 
> (Naturally I'm ignoring the slab accounting overhead).
> 
> Even a single-user system these days is going to have a gigabyte or more 
> of RAM, so we're talking less than a percent of memory tied up in this 
> case.  Three megabytes is probably less memory than a single Gnome 
> application uses for its working set.

:-)

> 
> I'm always told to start with a design that is as simple as possible 
> (and no simpler) and build on it only when I find a problem; this avoids 
> overdesign.  I don't see a compelling reason to start with a complicated 
> design here, and there are good reasons to keep it simple.

You are probably right.

> 
> If allowing the access cache to grow potentially without bounds still 
> makes you nervous, I maintain that we still want to avoid a global LRU. 
>   Having an LRU _per-inode_ might be a simple way to limit the amount of 
> memory that is consumed without the locking and management overhead of a 
> global LRU.  If entries haven't been accessed in more than actimeo 
> seconds, then purge them; we'll have to go back to the server to 
> revalidate such entries anyway, so there's no reason to keep them around.
> 
> It is pretty cheap to release, say, the two oldest entries every time 
> you try an access, provided they have not been touched in actimeo seconds.

If you want simple, a per-inode lru which is search linearly and
discards old entries as you suggest would probably be just right.
Leave the option of making a more sophisticated data structure if it
really seems necessary.

NeilBrown