Re: sched: CPU #1's llc-sibling CPU #0 is not on the same node!

From: Yinghai Lu
Date: Tue Feb 26 2013 - 01:57:42 EST

On Mon, Feb 25, 2013 at 10:09 PM, Tang Chen <tangchen@xxxxxxxxxxxxxx> wrote:
> On 02/26/2013 12:51 PM, Martin Bligh wrote:
>>> Do you mean we can remove numaq x86 32bit code now?
>> Wouldn't bother me at all. The machine is from 1995, end of life c. 2000?
>> Was useful in the early days of getting NUMA up and running on Linux,
>> but is now too old to be a museum piece, really.
>> M.
> Hi Martin, Yinghai,
> It was me that I failed to make numa_init() fall back path working, and
> forgot
> to call early_parse_srat in ia64. Sorry for the breaking of other platform.
> :)
> So now, is Yinghai's patch enough for this problem ?
> Or we can encapsulate the following clear up work into one function ?
> + for (i = 0; i < MAX_LOCAL_APIC; i++)
> + set_apicid_to_node(i, NUMA_NO_NODE);
> + nodes_clear(numa_nodes_parsed);
> + memset(&numa_meminfo, 0, sizeof(numa_meminfo));

That is temporary workaround and your patch and this workaround make
x86 acpi numa init too messy.

I don't see the point to hack SRAT to make memory hotplug working.

Do you guys check and use PMTT in ACPI spec instead?

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at