Bug 13216
Summary: | echo 3 > /proc/sys/vm/drop_caches doesn't really drop the caches | ||
---|---|---|---|
Product: | Memory Management | Reporter: | devsk (funtoos) |
Component: | Other | Assignee: | Andrew Morton (akpm) |
Status: | RESOLVED OBSOLETE | ||
Severity: | normal | CC: | alan, colanderman, funtoos, michal, richard.ems |
Priority: | P1 | ||
Hardware: | All | ||
OS: | Linux | ||
Kernel Version: | 2.6.30-rc4 | Subsystem: | |
Regression: | No | Bisected commit-id: | |
Attachments: |
This is after system has been used for while
This is after fresh boot |
Description
devsk
2009-04-30 18:52:56 UTC
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? |