I've been noticing this for a while (probably since at least 2.6.11 or so, but I haven't been keeping close attention), but I haven't had the time to get some proof that this was the cause, and to write it up until now. I have a T40 laptop (Pentium M processor) with 2 gigs of memory, and from time to time, after the system has been up for a while, the dentry cache grows huge, as does the ext3_inode_cache: slabinfo - version: 2.1 # name : tunables : slabdata dentry_cache 434515 514112 136 29 1 : tunables 120 60 0 : slabdata 17728 17728 0 ext3_inode_cache 587635 589992 464 8 1 : tunables 54 27 0 : slabdata 73748 73749 0 Leading to an impending shortage in low memory: LowFree: 9268 kB ... and if I don't take corrective measures, very shortly thereafter the system will become unresponsive and will end up thrashing itself to death, with symptoms that are identical to a case of 2.4 lowmem exhaustion --- except this is on a 2.6.13 kernel, where all of these problems were supposed to be solved. It turns out I can head off the system lockup by requesting the formation of hugepages, which will immediately cause a dramatic reduction of memory usage in both high- and low- memory as various caches and flushed: echo 100 > /proc/sys/vm/nr_hugepages echo 0 > /proc/sys/vm/nr_hugepages The question is why isn't the kernel able to figure out how to do release dentry cache entries automatically when it starts thrashing due to a lack of low memory? Clearly it can, since requesting hugepages does shrink the dentry cache: dentry_cache 20097 20097 136 29 1 : tunables 120 60 0 : slabdata 693 693 0 ext3_inode_cache 17782 17784 464 8 1 : tunables 54 27 0 : slabdata 2223 2223 0 LowFree: 835916 kB Has anyone else seen this, or have some ideas about how to fix it? Thanks, regards, - Ted