Bug 36624 - RFE: Inode cache needs tuning
RFE: Inode cache needs tuning
Status: CLOSED CURRENTRELEASE
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
7.1
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Arjan van de Ven
Brock Organ
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-04-19 05:40 EDT by Leos Bitto
Modified: 2007-04-18 12:32 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-06-05 20:29:11 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)

  None (edit)
Description Leos Bitto 2001-04-19 05:40:32 EDT
I boot my PC with stock Red at 7.1 installed and in a short time updatedb
is run by anacron. When it ends, this is how /proc/meminfo looks like:

        total:    used:    free:  shared: buffers:  cached:
Mem:  525586432 519958528  5627904        0 161689600 68882432
Swap: 542826496        0 542826496
MemTotal:       513268 kB
MemFree:          5496 kB
MemShared:           0 kB
Buffers:        157900 kB
Cached:          67268 kB
Active:         164436 kB
Inact_dirty:     58032 kB
Inact_clean:      2700 kB
Inact_target:      196 kB
HighTotal:           0 kB
HighFree:            0 kB
LowTotal:       513268 kB
LowFree:          5496 kB
SwapTotal:      530104 kB
SwapFree:       530104 kB

I am missing about 200 MB of RAM, and no process is using it (checked with
top). I think that updatedb triggers some bug in kernel which causes this
massive memory leak. I have three FAT32 partitions mounted, which are
indexed by updatedb, so maybe the problem is in there...
Comment 1 Arjan van de Ven 2001-04-19 05:48:42 EDT
I have a machine at home with several FAT partitions, I'll try to reproduce this
there.
Comment 2 Leos Bitto 2001-04-19 05:53:25 EDT
Oops, forget FAT, maybe I should have thought a bit more before submitting this
report. Now I unmounted all my FAT partitions, run updatedb (aka slocate.cron)
and surprise - the bug is still there. :(
Comment 3 Arjan van de Ven 2001-04-19 05:56:34 EDT
Could you do 
"dd if=/dev/zero of=/tmp/someweirdfile bs=1024 count=1000024" 
(eg create a 1 gb file)
and then
"rm /tmp/someweirdfile"

to see if this is just a cache or a real leak ?
Comment 4 Leos Bitto 2001-04-19 06:07:06 EDT
:-)))) Good try, but it's really not that easy - please do look at the
/proc/meminfo dump I sent. I tried that dd you suggested, but with with only 600
MB file - I don't have 1 GB free space right now. No problem appeared - sure,
the whole RAM got filled with cache, but that's OK.
Comment 5 Arjan van de Ven 2001-04-19 06:11:06 EDT
The question is, is the "leak" still there after this command?
There is one cache that isn't accounted in "buffers" or "cache" and that is
the "inode" cache (it's actually 2 caches in the kernel). It might be that they
are not trimmed agressively enough. The "dd" should provoke them being trimmed
anyway.
Comment 6 Leos Bitto 2001-04-19 06:19:30 EDT
After dd everything seems to be fine, no leak appears.
Here's /proc/meminfo:

        total:    used:    free:  shared: buffers:  cached:
Mem:  525586432 119160832 406425600        0  8896512 50581504
Swap: 542826496        0 542826496
MemTotal:       513268 kB
MemFree:        396900 kB
MemShared:           0 kB
Buffers:          8688 kB
Cached:          49396 kB
Active:          57268 kB
Inact_dirty:       816 kB
Inact_clean:         0 kB
Inact_target:     4840 kB
HighTotal:           0 kB
HighFree:            0 kB
LowTotal:       513268 kB
LowFree:        396900 kB
SwapTotal:      530104 kB
SwapFree:       530104 kB

If I understand it correctly, the dd command doesn't stress the inode cache,
does it?
Comment 7 Arjan van de Ven 2001-04-19 06:26:46 EDT
It doesn't. But it stresses the normal cache which then will ask the inode cache
to free up it's memory. So if the leak is gone after doing the "dd", it is the
inode cache. It then is not a leak, just a slightly misbalanced cache, which
will go away in time when you need memory.
Comment 8 Leos Bitto 2001-04-19 06:34:27 EDT
To be completely clear: I have rebooted between updatedb and dd. Later I tried
dd without reboot after updatedb, and it gave me some (but not all) memory back,
look:

        total:    used:    free:  shared: buffers:  cached:
Mem:  525586432 519598080  5988352        0 166608896 159481856
Swap: 542826496        0 542826496
MemTotal:       513268 kB
MemFree:          5848 kB
MemShared:           0 kB
Buffers:        162704 kB
Cached:         155744 kB
Active:         208132 kB
Inact_dirty:    107936 kB
Inact_clean:      2380 kB
Inact_target:    51840 kB
HighTotal:           0 kB
HighFree:            0 kB
LowTotal:       513268 kB
LowFree:          5848 kB
SwapTotal:      530104 kB
SwapFree:       530104 kB

It seems that you are right - it's a greedy inode cache. Welcome me to the
wonderful world of kernel 2.4. :)

Just of a curiosity: how can I see how much memory the inode cache occupies?
Comment 9 Arjan van de Ven 2001-04-19 16:26:09 EDT
You can't see right now. We're working on improving the cache-balance and
newer kernels seem to be better so far. 
I'll mark this bug as RFE (request for enhancement)
Comment 10 Leos Bitto 2001-04-19 16:57:11 EDT
OK, thanks. Tune the cache as needed, and could you please also make the inode
cache size visible somehow? An extra line in /proc/meminfo would be perfect.

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