From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030910 Description of problem: When you copy or create lots of new files the allocated inode_cache entries aren't being freed anymore, even after memory pressure. The problem is that the machine runs out of memory after some time, gets inresponsive and then unusable. kswapd eats 80% of the cpu time and the only thing left is to reset the machine. I'll attach a simple tarball with 100 directores each containing 100 files with each 5 bytes with which the problem can be easily reproduced. Watching /proc/slabinfo really shows that the number of inode_cache entries just increases but never decreases until you delete the newly generated files. Harald and i have tracked down the problem to patch Patch1000: linux-2.4.21-rmap.patch. If that one is left out everything works fine again. Read ya, Phil Version-Release number of selected component (if applicable): kernel-2.4.21-1.1931.2.405.ent How reproducible: Always Steps to Reproduce: 1. cd /usr/tmp 2. tar jxvf foo.tar.bz2 3. for i in `seq 0 100`; do rm -rf foo$i; done; 4. Watch your /proc/slabinfo inode_cache climb to unseen hights. :-) Actual Results: Machine gets slower and slower and virtually locks up with a kswapd running amok. Expected Results: inode_cache entries should be purged under memory pressure and machine should still be usable. Additional info:
Created attachment 94584 [details] Tarball with 10000 files
Created attachment 94585 [details] Tarball with 10000 files
steps to reproduce instead of 2), 3): 2, 3) $ for i in $(seq 1 100);do mkdir foo$i;tar -C foo$i -xjf ../foo.tar.bz2 ;echo $i;done
also with vanilla 2.4.21 and 2.4.21-rc6-rmap15k from http://surriel.com/patches/ 2.4.20-20.9 with rmap15c is not affected...
Erh, yes, of course, pasted wrong small script, sorry. And i am not sure if rmap15c is the one in 2.4.20-20.9 as the one from http://surriel.com/patches/ looks quite different to the one we have in that kernel, so checking righy now. Read ya, Phil
OK, i've really limited it now to the changes between rmap15d and rmap15e, as suspected. I've reviewed the code and didn't find anything directly obvious, will continue checking (e.g. if it's a problem with the new lists or with the vmscan handling). Read ya, Phil
Verified that the kernel-2.4.21-3.EL and later contains a fix that corrects the problem. Closing bug. Read ya, Phil