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

[Nishanth Aravamudan]

On 05.03.2015 [17:13:08 -0500], Tejun Heo wrote:
> On Thu, Mar 05, 2015 at 10:05:49AM -0800, Nishanth Aravamudan wrote:
> > 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