Re: [PATCH x86/mm UPDATED] x86-64, NUMA: Fix distance tablehandling

[David Rientjes]

On Wed, 2 Mar 2011, Tejun Heo wrote:

> > There's also this in numa_emulation() that isn't a safe assumption:
> > 
> >         /* make sure all emulated nodes are mapped to a physical node */
> >         for (i = 0; i < ARRAY_SIZE(emu_nid_to_phys); i++)
> >                 if (emu_nid_to_phys[i] == NUMA_NO_NODE)
> >                         emu_nid_to_phys[i] = 0;
> > 
> > Node id 0 is not always online depending on how you setup your SRAT.  I'm 
> > not sure why emu_nid_to_phys[] would ever map a fake node id that doesn't 
> > exist to a physical node id rather than NUMA_NO_NODE, so I think it can 
> > just be removed.  Otherwise, it should be mapped to a physical node id 
> > that is known to be online.
> 
> Unless I screwed up, that behavior isn't new.  It just put in a
> different form.  Looking through the code... Okay, I think node 0
> always exists.  SRAT PXM isn't used as node number directly.  It goes
> through acpi_map_pxm_to_node() which allocates nids from 0 up.
> amdtopology also guarantees the existence of node 0, so I think we're
> in the safe and that probably is the reason why we had the above
> behavior in the first place.
> 

The node may not have any memory or may be offline, which means we 
shouldn't be mapping fake nodes to it.  There shouldn't be any code that 
can't handle emu_nid_to_phys[] being NUMA_NO_NODE, otherwise there's a 
design issue.

> IIRC, there are other places which assume the existence of node 0.
> Whether it's a good idea or not, I'm not sure but requring node 0 to
> be always allocated doesn't sound too wrong to me.  Maybe we can add
> BUG_ON() if node 0 is offline somewhere.
> 

There shouldn't be because you can't guarantee it is online, it's not a 
BUG_ON() condition, it can easily be done if the pxm for node 0 in the 
SRAT is empty or non-existant.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/