lkml.org 
[lkml]   [2010]   [Jan]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [patch 6/6] x86: cpumask_of_node() should handle -1 as a node
On Thu, 7 Jan 2010, Anton Blanchard wrote:

> I don't like the use of -1 as a node, but it's much more widespread than
> x86; including sh, powerpc, sparc and the generic topology code. eg:
>
>
> #fdef CONFIG_PCI
> extern int pcibus_to_node(struct pci_bus *pbus);
> #else
> static inline int pcibus_to_node(struct pci_bus *pbus)
> {
> return -1;
> }

This seems to be the same semantics that NUMA_NO_NODE was defined for,
it's not necessarily a special case.

Regardless, the result of cpumask_of_node(NUMA_NO_NODE) should be
undefined as it currently is unless you want to obsolete NUMA_NO_NODE
entirely which is much more work. In other words, special-casing a nid of
-1 to mean no affinity is inappropriate if NUMA_NO_NODE represents an
invalid nid.

If x86 pci buses want to use -1 to imply that meaning, that's fine, but it
shouldn't be coded in a generic interface such as cpumask_of_node(). Does
that make sense?

> Speaking of invalid node ids, I also noticed the scheduler isn't using
> node iterators:
>
> for (i = 0; i < nr_node_ids; i++) {
>
> which should be fixed at some stage too since it doesn't allow us to
> allocate the node structures sparsely.
>

That loop has nothing to do with the allocation of a node structure, it's
quite plausible that it checks for various states such as node_online(i)
while looping and doing something else interesting for those that are
offline. Keep in mind that this isn't equivalent to using for_each_node()
since that only iterates over N_POSSIBLE which is architecture specific.


\
 
 \ /
  Last update: 2010-01-07 00:53    [from the cache]
©2003-2011 Jasper Spaans