Re: NUMA aware slab allocator V3

[Christoph Lameter]

On Mon, 16 May 2005, Dave Hansen wrote:

> There are some broken assumptions in the kernel that
> CONFIG_DISCONTIG==CONFIG_NUMA.  These usually manifest when code assumes
> that one pg_data_t means one NUMA node.
> 
> However, NUMA node ids are actually distinct from "discontigmem nodes".
> A "discontigmem node" is just one physically contiguous area of memory,
> thus one pg_data_t.  Some (non-NUMA) Mac G5's have a gap in their
> address space, so they get two discontigmem nodes.

I thought the discontigous memory in one node was handled through zones? 
I.e. ZONE_HIGHMEM in i386?

> So, that #error is bogus.  It's perfectly valid to have multiple
> discontigmem nodes, when the number of NUMA nodes is 1.  MAX_NUMNODES
> refers to discontigmem nodes, not NUMA nodes.

Ok. We looked through the code and saw that the check may be removed 
without causing problems. However, there is still a feeling of uneasiness 
about this.

To what node does numa_node_id() refer? And it is legit to use 
numa_node_id() to index cpu maps and stuff? How do the concepts of numa 
node id relate to discontig node ids?
-
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/