Neil Brown wrote:
On Wednesday May 3, cel@xxxxxxxxxxxxxx wrote:
For the sake of discussion, let me propose some design alternatives.
1. We already have cache shrinkage built in: when an inode is purged
due to cache shrinkage, the access cache for that inode is purged as
well. In other words, there is already a mechanism for external memory
pressure to shrink this cache. I don't see a strong need to complicate
matters by adding more cache shrinkage than already exists with normal
inode and dentry cache shrinkage.
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.
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.
--
corporate: <cel at netapp dot com>
personal: <chucklever at bigfoot dot com>
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
