public inbox for linux-ia64@vger.kernel.org
 help / color / mirror / Atom feed
From: Andi Kleen <ak@suse.de>
To: Christoph Lameter <clameter@engr.sgi.com>
Cc: Andi Kleen <ak@suse.de>,
	akpm@osdl.org, Christoph Hellwig <hch@infradead.org>,
	linux-ia64@vger.kernel.org, linux-kernel@vger.kernel.org,
	torvalds@osdl.org
Subject: Re: [PATCH 1/2] Zone reclaim V2
Date: Tue, 06 Dec 2005 18:09:20 +0000	[thread overview]
Message-ID: <20051206180920.GR11190@wotan.suse.de> (raw)
In-Reply-To: <Pine.LNX.4.62.0512060957160.18975@schroedinger.engr.sgi.com>

On Tue, Dec 06, 2005 at 10:01:28AM -0800, Christoph Lameter wrote:
> On Tue, 6 Dec 2005, Andi Kleen wrote:
> 
> > > An arch can control zone_reclaim by setting zone_reclaim_mode during bootup
> > > if it is discovered that the kernel is running on an NUMA configuration.
> > 
> > Looks much better. Thanks. But how about auto controlling the variable in generic
> > code based on node_distance() (at least for the non node hotplug case)
> 
> Any suggestions on how to determine zone reclaim behavior based on node 
> distances? AFAIK the main aspects in this are latency and bandwidth of 
> remote accesses. These vary depending on the distance of the remote node 
> under consideration.

I would enable it if distance for any combination of online (or possible?) nodes is 
> LOCAL_DISTANCE. I guess hotplug can be ignored for now.

If an architecture really needs something better it can be still refined. But there aren't 
that many NUMA architectures anyways, so it shouldn't be a big issue. 

It will actually need some tweaking on Opterons because many BIOS just
report 10 everywhere in SLIT and it should be still enabled, but that can be done 
in the architecture then.

-Andi


  reply	other threads:[~2005-12-06 18:09 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-12-06 17:24 [PATCH 1/2] Zone reclaim V2 Christoph Lameter
2005-12-06 17:24 ` [PATCH 2/2] Remove debris from old zone reclaim Christoph Lameter
2005-12-06 17:52 ` [PATCH 1/2] Zone reclaim V2 Andi Kleen
2005-12-06 18:01   ` Christoph Lameter
2005-12-06 18:09     ` Andi Kleen [this message]
2005-12-06 18:41       ` 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=20051206180920.GR11190@wotan.suse.de \
    --to=ak@suse.de \
    --cc=akpm@osdl.org \
    --cc=clameter@engr.sgi.com \
    --cc=hch@infradead.org \
    --cc=linux-ia64@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@osdl.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