On Wed, 2006-04-26 at 10:15 -0400, Peter Staubach wrote: > > > >What situations? AFAIA the number of processes in a typical setup are > >almost always far smaller than the number of cached inodes. > > > > > > > > The situation that doesn't scale is one where there are many different > users on the system. It is the situation where there are more then just > a few users per file. This can happen on compute servers or systems > used for timesharing sorts of purposes. Yes, but the number of users <= number of processes which even on those systems is almost always much, much less than the number of cached inodes. > >For instance on my laptop, I'm currently running 146 processes, but > >according to /proc/slabinfo I'm caching 330000 XFS inodes + 141500 ext3 > >inodes. > >If I were to assume that a typical nfsroot system will show roughly the > >same behaviour, then it would mean that a typical bucket in Steve's 256 > >hash entry table will contain at least 2000 entries that I need to > >search through every time I want to do an access call. > > > > For such a system, there needs to be more than 256 hash buckets. The number > of the access cache hash buckets needs to be on scale with the number of > hash > buckets used for similarly sized caches and tables. The inode cache is the only similarly sized cache I can think of. That is set either by the user, or it takes a default value of (total memory size) / 2^14 buckets (see alloc_large_system_hash). On a 1Gb system, that makes the default hash table size ~ 65536 entries. I can't see people wanting to put up with a 256K static hash table for access caching too. Furthermore, note that the inode cache is only searched when initialising a dentry. It is not searched on _every_ traversal of a path element. Cheers, Trond - 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
