On Sunday May 7, cel@xxxxxxxxxxxxxx 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 - 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
