linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Christoph Lameter <clameter@engr.sgi.com>
To: Andrew Morton <akpm@osdl.org>
Cc: linux-mm@kvack.org
Subject: Re: [PATCH] Zone reclaim: Allow modification of zone reclaim behavior
Date: Mon, 30 Jan 2006 13:59:40 -0800 (PST)	[thread overview]
Message-ID: <Pine.LNX.4.62.0601301350580.5341@schroedinger.engr.sgi.com> (raw)
In-Reply-To: <20060130134554.500b73a3.akpm@osdl.org>

On Mon, 30 Jan 2006, Andrew Morton wrote:

> The proliferating /proc configurability is a worry.  It'll confuse people
> and people just won't know that it's there and it's yet another question
> which maintenance people need to ask end-users during problem resolution.
> 
> Is there not some means by which we can simply get these things right?

I wish I knew some other way to do this. We will have to do significant 
changes to the VM to even have the data available to make the proper 
decisions in these settings. See my zone based counter patches from before 
Christmas. These allow to get rid of the reclaim_interval but are so 
extensive you would not want them for 2.6.16. More brainwork is needed 
after the counters are in to figure out way to make the other knobs 
unnecessary.

> Why wouldn't we want to perform writeback or swapout during zone reclaim?

Because that will reduce performance. If writeback is performed during 
reclaim then a process cannot dirty all of available memory. It will be 
throttled after using up all of a nodes memory. This is a significant 
regression from current performance.

If you do swapout then the process is restricted to a node and will start 
swapping if more memory starts being used than a node has avalable. This 
is going to drastically reduce performance.

zone_reclaim in its default configuration is simply throwing out pages 
that have no references left. These are pagecache pages that may be left 
from a copy operation or from an application that has terminated.

> Why wouldn't we want to reclaim slab during zone reclaim?

Because its too expensive to do and because slab reclaim is not able to 
cleanly reclaim per zone right now. It does a global shrink operation on 
nodes that may still have lots of memory available.

We can skip some of these for 2.6.16 if you do not want the knobs. The 
default behavior without the knobs should be fine for most cases.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

      reply	other threads:[~2006-01-30 21:59 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-01-30 20:24 Christoph Lameter
2006-01-30 21:45 ` Andrew Morton
2006-01-30 21:59   ` Christoph Lameter [this message]

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=Pine.LNX.4.62.0601301350580.5341@schroedinger.engr.sgi.com \
    --to=clameter@engr.sgi.com \
    --cc=akpm@osdl.org \
    --cc=linux-mm@kvack.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox