Re: [RFC PATCH] powerpc/numa: reset node_possible_map to only node_online_map

On 05.03.2015 [17:13:08 -0500], Tejun Heo wrote:

On Thu, Mar 05, 2015 at 10:05:49AM -0800, Nishanth Aravamudan wrote:

quoted

While looking at this, I noticed that nr_node_ids is actually a
misnomer, it seems. It's not the number, but the maximum_node_id, as
with sparse NUMA nodes, you might only have two NUMA nodes possible, but
to make certain loops work, nr_node_ids will be, e.g., 17. Should it be
changed?

It's the same for nr_cpu_ids.  It's counting the number of valid IDs
during that boot instance.  In the above case, whether the nodes are
sparse or not, there exist 17 node ids - 0 to 16.  Maybe numa_max_id
had been a better name (but would that equal the highest number or
+1?) but nr_node_ids != nr_nodes so I don't think it's a misnomer
either.  Doesn't really matter at this point.  Maybe add comments on
top of both?

Yes, I will consider that. To me, I guess it's more a matter of:

a) How does nr_node_ids relate to the number of possible NUMA node IDs
at runtime?

They are identical.

b) How does nr_node_ids relate to the number of NUMA node IDs in use?

There is no relation.

c) How does nr_node_ids relate to the maximum NUMA node ID in use?

It is one larger than that value.

However, for a), at least, we don't care about that on power, really. We
don't have node hotplug, so the "possible" is the "online" in practice,
for a given system.

Iteration seems to generally not be a problem (since we have sparse
iterators anyways) and we shouldn't be allocating for non-present nodes.

But we run into excessive allocations (I'm looking into a few others
Dipankar has found now) with array allocations based of nr_node_ids or
MAX_NUMNODES when the NUMA topology is sparse..

-Nish