Bug 104652 - Kernel doesn't free inode_cache after copy...
Kernel doesn't free inode_cache after copy...
Status: CLOSED RAWHIDE
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: kernel (Show other bugs)
3.0
All Linux
medium Severity high
: ---
: ---
Assigned To: Arjan van de Ven
Brian Brock
:
Depends On:
Blocks: 97942
  Show dependency treegraph
 
Reported: 2003-09-18 10:10 EDT by Phil Knirsch
Modified: 2015-03-04 20:12 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-10-17 04:38:22 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Tarball with 10000 files (18.33 KB, text/plain)
2003-09-18 10:10 EDT, Phil Knirsch
no flags Details
Tarball with 10000 files (18.33 KB, application/octet-stream)
2003-09-18 10:11 EDT, Phil Knirsch
no flags Details

  None (edit)
Description Phil Knirsch 2003-09-18 10:10:00 EDT
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:
Comment 1 Phil Knirsch 2003-09-18 10:10:51 EDT
Created attachment 94584 [details]
Tarball with 10000 files
Comment 2 Phil Knirsch 2003-09-18 10:11:04 EDT
Created attachment 94585 [details]
Tarball with 10000 files
Comment 3 Harald Hoyer 2003-09-18 14:04:22 EDT
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
Comment 4 Harald Hoyer 2003-09-18 14:06:36 EDT
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...
Comment 5 Phil Knirsch 2003-09-18 14:08:42 EDT
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
Comment 6 Phil Knirsch 2003-09-19 08:08:03 EDT
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
Comment 8 Phil Knirsch 2003-10-17 04:38:22 EDT
Verified that the kernel-2.4.21-3.EL and later contains a fix that corrects the
problem. Closing bug.

Read ya, Phil

Note You need to log in before you can comment on or make changes to this bug.