lkml.org 
[lkml]   [2006]   [Feb]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH 1/5] cpuset memory spread basic implementation
Date
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/

\
 
 \ /
  Last update: 2006-02-06 19:51    [W:0.085 / U:0.400 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site