Re: [PATCH] GFP_THISNODE for the slab allocator

[Andrew Morton <akpm@osdl.org>]

On Sat, 16 Sep 2006 14:51:17 -0700
Paul Jackson <pj@sgi.com> wrote:

> Andrew wrote:
> > Pretty much all loads?  If you haven't consumed most of the "container"'s
> > memory then you have overprovisioned its size.
> 
> Not so on real NUMA boxes.

I meant pretty much all loads when employing this trick of reusing the NUMA
code for containerisation.

>  If you configure your system so that
> you are having to go a long way off-node for much of your memory,
> then your performance is screwed.
> 
> No one in their right mind would run a memory hog that eats 40 nodes
> of memory and a kernel build both in the same 60 node, small CPU
> count cpuset on a real NUMA box.
> 
> The primary motivation for cpusets is to improve memory locality on
> NUMA boxes.  You're using fake numa and cpusets to simulate destroying
> memory locality.
> 
> On a real 64 node NUMA box, there would be 64 differently sorted
> zonelists, each one centered on a different node.  The kernel build
> would be running on different CPUs, associated with different nodes
> than the memory hog, and it would be using zonelists that had the
> unloaded (still has free memory) nodes at the front the list.
> 
> Aha - maybe this is the problem - the fake numa stuff is missing the
> properly sorted zone lists.

I don't see how any of this could help.  If one has a memory container
which is constructed from 50 zones, that linear search is just going to do
a lot of linear searching when the container approaches anything like
fullness.

It could well be a single CPU machine...

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>