If you consult /proc/meminfo, you'll see that updatedb causes a massive increase in slab size.
It turns out that this isn't a problem for the system: starting a memory-hungry application causes that space to be reclaimed. (I used Unreal Tournament 2004 to demonstrate this, but I'm sure you can think of others.) If I start UT2004, start playing a level, exit UT2004 (and wait a few seconds for it to completely exit), the slab size drops to about 21MB. The top 5 items shown by slabtop are: 18909 5169 27% 0.43K 2101 9 8404K ext3_inode_cache 30938 5065 16% 0.12K 998 31 3992K dentry_cache 3962 1128 28% 0.27K 283 14 1132K radix_tree_node 3058 911 29% 0.36K 278 11 1112K fat_inode_cache 256 256 100% 3.00K 128 2 1024K biovec-(256) If I then run updatedb, and wait for it to complete, the slab size jumps to about 102MB, with the top 5 items as follows: 133533 133525 99% 0.43K 14837 9 59348K ext3_inode_cache 171802 171786 99% 0.12K 5542 31 22168K dentry_cache 36421 36420 99% 0.36K 3311 11 13244K fat_inode_cache 78858 78697 99% 0.05K 1011 78 4044K buffer_head 5880 5866 99% 0.27K 420 14 1680K radix_tree_node This cycle is fairly repeatable. Based on my very limited understanding of kernel memory management, I think that the actual bug is that free, top, etc. consider "slab" to be "used" rather than some sort of buffers/cache, which seems to be a more accurate description. http://www.mjmwired.net/kernel/Documentation/filesystems/proc.txt#421 "Slab: in-kernel data structures cache" So this is not a bug in findutils or the kernel, but maybe it should be reassigned to procps, and possibly duplicated to other packages that might misinterpret /proc/meminfo? -- graham -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
