From: Andi Kleen <ak@suse.de>
To: Christoph Lameter <clameter@engr.sgi.com>
Subject: Re: [PATCH 1/5] cpuset memory spread basic implementation
Date: Mon, 6 Feb 2006 19:48:24 +0100
User-Agent: KMail/1.8.2
Cc: Paul Jackson <pj@sgi.com>, mingo@elte.hu, akpm@osdl.org, dgc@sgi.com,
       steiner@sgi.com, Simon.Derr@bull.net, linux-kernel@vger.kernel.org
References: <20060204071910.10021.8437.sendpatchset@jackhammer.engr.sgi.com> <200602061936.27322.ak@suse.de> <Pine.LNX.4.62.0602061039420.16829@schroedinger.engr.sgi.com>
In-Reply-To: <Pine.LNX.4.62.0602061039420.16829@schroedinger.engr.sgi.com>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200602061948.25314.ak@suse.de>
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1204
Lines: 30

On Monday 06 February 2006 19:43, Christoph Lameter wrote:

> The impact of spreading cached object will depend on the application and 
> the NUMA latencies in the system.

Yes I can see it not working well when a dentry is put at the other 
end of a 256 node altix. That is why just spreading it to nearby
nodes might be an alternative.

On the other hand global interleaving actually worked for the page cache 
in production in SLES9, so it can't be that bad.

Also I'm sure you can construct some workload where it is a major loss.
For those one has NUMA policy to adjust it (although I don't know yet
how to apply separate numa policy to the d/i/file page cache - but if 
it should be a real problem it could be surely solved somehow)

The question is just if it's a common situation. My guess is that just
giving local memory priority but not throwing away all IO caches
when the local node fills up would be a generally useful default policy.

-Andi


>
-
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/