Re: NUMA aware slab allocator V3

[Christoph Lameter]

On Mon, 16 May 2005, Dave Hansen wrote:

> > How do the concepts of numa node id relate to discontig node ids?
> 
> I believe there are quite a few assumptions on some architectures that,
> when NUMA is on, they are equivalent.  It appears to be pretty much
> assumed everywhere that CONFIG_NUMA=y means one pg_data_t per NUMA node.

Ah. That sounds much better.

> Remember, as you saw, you can't assume that MAX_NUMNODES=1 when NUMA=n
> because of the DISCONTIG=y case.

I have never seen such a machine. A SMP machine with multiple 
"nodes"? So essentially one NUMA node has multiple discontig "nodes"?

This means that the concept of a node suddenly changes if there is just 
one numa node(CONFIG_NUMA off implies one numa node)? 

> So, in summary, if you want to do it right: use the
> CONFIG_NEED_MULTIPLE_NODES that you see in -mm.  As plain DISCONTIG=y
> gets replaced by sparsemem any code using this is likely to stay
> working.

s/CONFIG_NUMA/CONFIG_NEED_MULTIPLE_NODES?

That will not work because the idea is the localize the slabs to each 
node. 

If there are multiple nodes per numa node then invariable one node in the 
numa node (sorry for this duplication of what node means but I did not 
do it) must be preferred since numa_node_id() does not return a set of 
discontig nodes.
 
Sorry but this all sounds like an flaw in the design. There is no 
consistent notion of node. Are you sure that this is not a ppc64 screwup?

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/