Re: NUMA aware slab allocator V3

Christoph Lameter
2005-05-16T16:47:51Z

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?