Red Hat Bugzilla – Full Text Bug Listing
|Summary:||RFE: Inode cache needs tuning|
|Product:||[Retired] Red Hat Linux||Reporter:||Leos Bitto <bitto>|
|Component:||kernel||Assignee:||Arjan van de Ven <arjanv>|
|Status:||CLOSED CURRENTRELEASE||QA Contact:||Brock Organ <borgan>|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2003-06-05 20:29:11 EDT||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
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.