All of lore.kernel.org
 help / color / mirror / Atom feed
From: Con Kolivas <kernel@kolivas.org>
To: "Pradeep Vincent" <pradeep.vincent@gmail.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Priority in Memory management
Date: Fri, 17 Mar 2006 21:29:01 +1100	[thread overview]
Message-ID: <200603172129.01490.kernel@kolivas.org> (raw)
In-Reply-To: <9fda5f510603170037v41d273c5naf36776e6f03246e@mail.gmail.com>

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

  reply	other threads:[~2006-03-17 10:29 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-03-17  8:37 Priority in Memory management Pradeep Vincent
2006-03-17 10:29 ` Con Kolivas [this message]
2006-03-17 17:46 ` Christoph Lameter

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200603172129.01490.kernel@kolivas.org \
    --to=kernel@kolivas.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pradeep.vincent@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.