[lkml]   [2010]   [Jan]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    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    [W:0.021 / U:50.432 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site