Ehh, I read that as 1MB for the dentry cache and .5MB for the inode
cache, Which is several orders less than 1GB. Ofcourse these are only
the pointers to the chains of dentries and inodes which take up far more
than just 8 bytes per entry. And once you have to start traversing those
hashchains you're toast.
> Try the appended experimental patch. It replaces the hash table madness
> with relatively small fixed tables. The actual size is probably left
> for experimentation. I choose 64K for inode and 128K for dcache for now.
And as a result you are probably just making the length of any given
hashchain longer, and walking the chain is painful as the referenced
objects are actually scattered throughout memory.
Another optimization is to leave the tables big (scaled up with memory
size), but try to keep the chains as short as possible. f.i. when adding
a new entry to a non-empty chain, drop the old entry if it isn't used.
That would give a lot more control over the actual size of the dentry
and inode caches, so that updatedb runs won't push these caches to
completely take over the VM.
Jan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/