From: Andi Kleen <ak@suse.de>
To: Ingo Molnar <mingo@elte.hu>
Subject: Re: [PATCH 1/5] cpuset memory spread basic implementation
Date: Mon, 6 Feb 2006 11:16:42 +0100
User-Agent: KMail/1.8.2
Cc: Paul Jackson <pj@sgi.com>, akpm@osdl.org, dgc@sgi.com, steiner@sgi.com,
       Simon.Derr@bull.net, linux-kernel@vger.kernel.org, clameter@sgi.com
References: <20060204071910.10021.8437.sendpatchset@jackhammer.engr.sgi.com> <200602061109.45788.ak@suse.de> <20060206101156.GA1761@elte.hu>
In-Reply-To: <20060206101156.GA1761@elte.hu>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200602061116.44040.ak@suse.de>
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1039
Lines: 26

On Monday 06 February 2006 11:11, Ingo Molnar wrote:
> 
> * Andi Kleen <ak@suse.de> wrote:
> 
> > Of course there might be some corner cases where using local memory 
> > for caching is still better (like mmap file IO), but my guess is that 
> > it isn't a good default.
> 
> /tmp is almost certainly one where local memory is better.

Not sure. What happens if someone writes a 1GB /tmp file on a 1GB node?

Christoph recently added some changes to the page allocator to 
try harder to get local memory to work around this problem, but
attacking it at the root might be better.

Perhaps one could do a "near" caching policy for big machines: e.g. 
if on a big Altix prefer to put it on a not too far away node, but
spread it out evenly. But it's not clear yet such complexity is needed.

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