It seems that the dentry preshrinking stuff has been fixed -- it now
doesn't end up half-shrinking itself as it grows and so the first time
something creates a bunch of dcache records, it works perfectly the second
time (previously it used to have to run 3 or 4 times before the dcache
allowed itself to grow enough)...And it seems to be limiting itself to
mirror inode-max, which is fine (I just upped it a bit to be happy with
the insane number of zone files the nameserver is loading).
BUT...in my experiment as the named process was slowly eating up RAM
(about 64k/sec), my box froze for about a second and resumed, right as it
hit low memory. My console displaying /proc/sys/fs/dentry-state showed a
drop from about 16,000 to completely nothing.
Why? prune_dcache() is being called with count=0, and this causes count
to wrap in the if condition:
if (!--count)
break;
prune_dcache(0) is called from shrink_dcache_memory() which appears
(according to the comment) to originally support some form of shrinking
priority, but was changed to just prune_dcache(0) (which is now toasting
everything). shrink_dcache_memory() is called from
do_try_to_free_pages(), meaning that we're toasting the dcache each and
every time nr_free_pages falls too low.
Unless I'm missing something, I think there's something wrong here. :)
This change appears to have been made between in the real 2.2.0, with
some changes made before in the 2.2.0-final patch.
Simon-
| Simon Kirby | Systems Administration |
| mailto:sim@netnation.com | NetNation Communications |
| http://www.netnation.com/ | Tech: (604) 684-6892 |
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/