Priority in Memory management

Priority in Memory management

[Pradeep Vincent]

I tried searching for discussions related to this but in vain A
significant number of servers running Linux come under the category of
"Caching Servers". These servers usually try to server data either
from RAM or disk sub-systems and for obvious reasons want to serve as
much data as possible from RAM. Even if the dataset is comparable to
RAM size, other bon-performance critical activities on the system
(such as logging, log rotation/compression, remote performance
monitors, application code updates, security related searches )
disturb the cache hit ratio.

Mlocking the dataset is one option. Using fadvise/O_STREAM for
everything else is another option - but this doesn't address all the
cases.

Instead of locking out all memory, being able to set priorities for
virtual memory regions comes across as a better idea. This way if the
system really really needs memory, kernel can reclaim the cache pages
but not just because somebody is writing something and it might seem
fair to reclaim the dataset cache.


Has this come up in the past. Any history at all - I am all ears for
ideas and concerns.

Thanks,

Pradeep Vincent

Re: Priority in Memory management

[Con Kolivas]

On Friday 17 March 2006 19:37, Pradeep Vincent wrote:
> I tried searching for discussions related to this but in vain A
> significant number of servers running Linux come under the category of
> "Caching Servers". These servers usually try to server data either
> from RAM or disk sub-systems and for obvious reasons want to serve as
> much data as possible from RAM. Even if the dataset is comparable to
> RAM size, other bon-performance critical activities on the system
> (such as logging, log rotation/compression, remote performance
> monitors, application code updates, security related searches )
> disturb the cache hit ratio.
>
> Mlocking the dataset is one option. Using fadvise/O_STREAM for
> everything else is another option - but this doesn't address all the
> cases.
>
> Instead of locking out all memory, being able to set priorities for
> virtual memory regions comes across as a better idea. This way if the
> system really really needs memory, kernel can reclaim the cache pages
> but not just because somebody is writing something and it might seem
> fair to reclaim the dataset cache.
>
>
> Has this come up in the past. Any history at all - I am all ears for
> ideas and concerns.

True priority support in the form of a "vm scheduler" is something I've 
mentioned many times in the past. The overhead would not be insignificant. 
Nonetheless I do have some weak priority support for page reclaiming in my 
-ck tree because doing so was not overly expensive. As far as I'm aware noone 
is currently working on a comprehensive vm scheduler.

Cheers,
Con

Re: Priority in Memory management

[Christoph Lameter]

On Fri, 17 Mar 2006, Pradeep Vincent wrote:

> Instead of locking out all memory, being able to set priorities for
> virtual memory regions comes across as a better idea. This way if the
> system really really needs memory, kernel can reclaim the cache pages
> but not just because somebody is writing something and it might seem
> fair to reclaim the dataset cache.

Use the zone_reclaim feature in 2.6.16. zone reclaim will remove page 
cache pages if the memory on a node gets too tight. If you are on a 
non-NUMA system then light swapping will do the same.