On 07/14/2010 12:49 PM, Flaherty, Patrick wrote:
I did some testing a while back, and my results showed that the -/+ buffers line seemed to be the *Minimum* amount of ram available if the kernel purged it's buffers/cache. Sometimes more is available.
That can be the case if your kernel is configured to overcommit (it normally is), and the applications haven't actually written data to all of the pages that they've allocated.
(Roughly) The test was:
- Turn swap off
- Run free
- Run 20 instances of a test program that malloc'd 100 megs of ram
- Run free, see 2 gigs of ram + orginal amount of ram used.
- Kill N number of those programs, which should free up N*100megs
- Run free, output of -/+ did not reflect 2gigs - (N*100 megs).
You'd see different results if you malloc() 100MB of memory and write 0s to each page.
I followed up by running enough instances of the test program that I should have run out of memory free said I had, but the programs all started, none were killed. I ran free again got a number pretty close to what I thought should be free. It's a fun test to play with, I assume results vary from kernel to kernel (how aggressive the kernel is cleaning up returned ram).
IIRC, Linux doesn't do any cleaning up of memory that's returned. Some OSs do. Might also be worth mentioning that depending on which malloc you use, free() usually returns memory only to the process' own memory allocator, not to the kernel. Most of the time, the kernel only gets memory back when the application exits.