[lkml]   [2011]   [Mar]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH x86/mm UPDATED] x86-64, NUMA: Fix distance table handling

On Wed, Mar 02, 2011 at 06:30:59AM -0800, David Rientjes wrote:
> Acked-by: David Rientjes <>
> 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.

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.



 \ /
  Last update: 2011-03-02 16:45    [W:0.101 / U:0.652 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site