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...
I have a machine at home with several FAT partitions, I'll try to reproduce this there.
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. :(
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 ?
:-)))) 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.
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.
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?
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.
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?
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)
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.