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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
