Re: la la la la ... swappiness

[Kyle Moffett <mrmacman_g4@mac.com>]

On Dec 03, 2006, at 20:54:41, Aucoin wrote:
> As a side note, even now, *hours* after the tar has completed and  
> even though I have swappiness set to 0, cache pressure set to 9999,  
> all dirty timeouts set to 1 and all dirty ratios set to 1, I still  
> have a 360+K inactive page count and my "free" memory is less than  
> 10% of normal.
The point you're missing is that an "inactive" page is a free page  
that happens to have known clean data on it corresponding to  
something on disk.  If you need to use the inactive page for  
something all you have to do is either zero it or fill it with data  
from elsewhere.  There is _no_ practical reason for the kernel to  
turn an "inactive" page into a "free" page.  On my Linux systems  
after heavy local-disk and network intensive read-only load I have no  
more than 2% "free" memory, most of the rest is "inactive" (in one  
case some 2GB of it).  There's nothing _wrong_ with that much  
"inactive" memory, it just means that you were using it for data at  
one point, then didn't need it anymore and haven't reused it since.
> I'm not pretending to understand what's happening here but  
> shouldn't some kind of expiration have kicked in by now and freed  
> up all those inactive pages?
Nope; the pages will continue to contain valid data until you  
overwrite them with new data somehow.  Now, if they were "dirty"  
pages, containing unwritten data, then you would be correct.
> The *instant* I manually push a "3" into drop_caches I have 100% of  
> my normal free memory and the inactive page count drops below 2K.  
> Maybe I completely misunderstood the purpose of all those dials but  
> I really did get the feeling that twisting them all tight would  
> make the housekeeping algorithms more aggressive.
In this case you're telling the kernel to go beyond its normal  
housekeeping and delete perfectly good data from memory.  The only  
reason to do that is usually to make benchmarks mildly more  
repeatable and doing it on a regular basis tends to kill performance.
Cheers,
Kyle Moffett

> [copy of long previous email snipped]
PS: No need to put a copy of the entire message you are replying to  
at the end of your post, it just chews up space.  If anything please  
quote inline immediately before the appropriate portion of your reply  
so we can get the gist, much as I have done above.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/