I have seen this happening in all recent kernels. And it happens in 2.6.30-rc4 as well. With passage of time, the minimum amount of "Cached" keeps on increasing. I say minimum because even if I do a 'echo 3 > drop_caches' in a while true loop for extended periods of time, it can not free cache beyond a point. After a fresh boot, that point was about 300MB on a 2GB RAM machine. Now it stands at 560MB. And its increasing without any real activity on the system. The laptop has been suspended to RAM a couple of times since I saw that 300MB number and it has been up just 10 hours. I suspect that this leads to eventual heavy swapping on my laptop and system becomes unusable. Let me know what information do you need to debug this. The only change from defaults is "vm.swappiness = 5".
Is there something that I need to provide for someone to make some progress on this issue? This is a very clearly defined issue. Why are we not dropping caches under memory pressure or on request through echo 3 > drop_caches? Why do we prefer to swap than get rid of cache, even with swappiness at 1 (tried the whole range of values from 1 to 100)? My laptop becomes unusable (with nothing going on in it) after few days of uptime and reaches a stage where four finger salute is the only thing that works, if at all. And we are talking about a system with 2GB RAM, not 256MB.
Sounds like a memory leak. Please report this via email so we can work on it more easily. Suitable recipients are: linux-mm@kvack.org Andrew Morton <akpm@linux-foundation.org> Rik van Riel <riel@redhat.com> KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> It would be helpful to include the following data after running the drop-caches operation, on a freshly booted system and also on a misbehaving system: cat /proc/meminfo cat /proc/vmstat dmesg -c > /dev/null ; echo m > /proc/sysrq-trigger ; dmesg -c Thanks.
Created attachment 21309 [details] This is after system has been used for while
Created attachment 21310 [details] This is after fresh boot
Is there anything obvious in those logs? I am getting a lost session in KDE4.2 after resume (I don't know if its related but I did see messages where X couldn't allocate pages). So, I am gonna try and upgrade to rc5 and see if that helps. Is there any other information you need from rc4? >> Please report this via email Is that mailing list open?
I think I am hitting the same bug here. We have a system with 16 GB memory and free reports # free total used free shared buffers cached Mem: 16437916 16305248 132668 0 2104 470976 -/+ buffers/cache: 15832168 605748 Swap: 2104504 0 2104504 A process was reading a 3.2 GB binary file and died with this error: A request for memory failed. This is typically due to insufficient virtual memory.: Command: ExecuteReport In: [Machine::main] Recoverability: Non-recoverable error: Server Error Thereafter the memory doesn't get freed neither by the process nor by the kernel and further processes start swapping. echo 3 > /proc/sys/vm/drop_caches does not help either. Can this memory be released somehow without rebooting? This happened already on another system with exact the same symptoms. Only a reboot helped then. Is this bug being discussed elsewhere? thanks, Richard
sorry, forgot some more system data: openSUSE 11.1, 64 bit # uname -a Linux c4fat 2.6.27.29-0.1-default #1 SMP 2009-08-15 17:53:59 +0200 x86_64 x86_64 x86_64 GNU/Linux Can I help somehow with more data or doing any tests?
Seeing this in 2.6.31 still. echo 3 | sudo tee drop_caches leaves 250MB cached on a 1GB machine, even with tmpfs near-empty (<1MB used) and swap off. Even some hint on how to hack around this would be appreciated as this tends to bring my machine to a crawl. Let me know what info I can provide / tests I can perform to help with the issue.
I wonder how much does the slab fragmentation have to do with this. Is there a way (like print some stats) to rule out this possibility?