Re: [PATCH 1/5] cpuset memory spread basic implementation

[Christoph Lameter <clameter@engr.sgi.com>]

On Mon, 6 Feb 2006, Andi Kleen wrote:

> > AFAIK you can reach these low latency factors only if multiple nodes are 
> > on the same motherboard. Likely Opteron specific?
> 
> Should be true for most CPUs with integrated memory controller.

Even the best memory controller cannot violate the laws of physics 
(electrons can at maximum travel with the speed of light). Therefore
cable lengths have a major influence on the latency of signals.

> > I dont understand you here. What would be the benefit of selecting more 
> > distant memory over local? I can only imagine that this would be 
> > beneficial if we know that the data would be used later by other 
> > processes.
> 
> The benefit would be to not fill up the local node as quickly when
> you do something IO (or dcache intensive).  And on contrary when you
> do something local memory intensive on that node then you won't need
> to throw away all the IO caches if they are already spread out.

An efficient local reclaim should deal with that situation. zone_reclaim 
will free up portions of memory in order to stay on node.

> The kernel uses of these cached objects are not really _that_ latency 
> sensitive and not that frequent so it makes sense to spread it out a 
> bit to nearby nodes.

The impact of spreading cached object will depend on the application and 
the NUMA latencies in the system.
-
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/