Bug 13216 - echo 3 > /proc/sys/vm/drop_caches doesn't really drop the caches
Summary: echo 3 > /proc/sys/vm/drop_caches doesn't really drop the caches
Status: RESOLVED OBSOLETE
Alias: None
Product: Memory Management
Classification: Unclassified
Component: Other (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: Andrew Morton
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-04-30 18:52 UTC by devsk
Modified: 2012-10-30 17:22 UTC (History)
5 users (show)

See Also:
Kernel Version: 2.6.30-rc4
Subsystem:
Regression: No
Bisected commit-id:


Attachments
This is after system has been used for while (279.85 KB, text/plain)
2009-05-12 03:13 UTC, devsk
Details
This is after fresh boot (3.76 KB, text/plain)
2009-05-12 03:14 UTC, devsk
Details

Description devsk 2009-04-30 18:52:56 UTC
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".
Comment 1 devsk 2009-05-05 19:05:54 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.
Comment 2 Andrew Morton 2009-05-05 21:21:44 UTC
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.
Comment 3 devsk 2009-05-12 03:13:28 UTC
Created attachment 21309 [details]
This is after system has been used for  while
Comment 4 devsk 2009-05-12 03:14:20 UTC
Created attachment 21310 [details]
This is after fresh boot
Comment 5 devsk 2009-05-12 20:08:39 UTC
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?
Comment 6 Richard Ems 2009-10-20 10:41:35 UTC
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
Comment 7 Richard Ems 2009-10-20 10:43:30 UTC
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?
Comment 8 Chris King 2010-01-30 02:35:52 UTC
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.
Comment 9 devsk 2010-01-30 03:17:48 UTC
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?

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