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

From: Tang Chen
Date: Thu Feb 28 2013 - 21:00:20 EST

On 03/01/2013 12:07 AM, Yinghai Lu wrote:
On Tue, Feb 26, 2013 at 11:44 PM, Tang Chen<tangchen@xxxxxxxxxxxxxx> wrote:

Sorry, if you want to revert, you just need to revert:

commit e8d1955258091e4c92d5a975ebd7fd8a98f5d30f
acpi, memory-hotplug: parse SRAT before memblock is ready
commit 01a178a94e8eaec351b29ee49fbb3d1c124cb7fb
acpi, memory-hotplug: support getting hotplug info from SRAT

The other two have nothing to do with SRAT. And they are necessary.

Seeing from the code, I think it is clean. But we'd better test it.

We should revert them all.


commit fb06bc8e5f42f38c011de0e59481f464a82380f6
Author: Tang Chen<tangchen@xxxxxxxxxxxxxx>
Date: Fri Feb 22 16:33:42 2013 -0800

page_alloc: bootmem limit with movablecore_map

It is totally misleading in the TITLE. Come on, what is movablecore_map?

It actually use movablemem_map to exclude some range during

That make memblock less generic.

That patch is the base of the whole patchset.

Also you and Yasuaki keep saying: movablemem_map=srat.
But where is doc and code for it?
Looks like there is only movablemem_map=acpi.

Hi Yinghai,

I think I forgot to change the title when merging the related bugfix patches
into one. And yes, movablecore_map has been changed to movablemem_map.

How about this:

For now, let's revert the SRAT related patch, and keep movablecore_map=nn[KMG]@ss[KMG].

About the SRAT thing, we have the following solution:

1) keep the original init series, parse acpi tables and modify global variables as before
2) introduce a new function to obtain SRAT info earlier, store the info somewhere,
and touch no numa related thing
3) use the info to do movablemem_map thing, and free them when it is done

In this way, we keep our code isolated from numa code. And the numa will be initialized as before.
This can be done in one week or faster. And I'll cc x86 guys, and they can choose whenever
to merge the new code.

And about movablecore_map=nn[KMG]@ss[KMG] code, there is no harm to the kernel. And we
have documented it that using this option will cause numa performance down. And users who
don't want to lose the numa performance can boot the kernel without this option, and the
kernel will work as before.

I do hope we can keep the code in 3.9, and do more improvement in the future.
So please just revert the two SRAT related patches.

Thanks. :)

I'm upset by this patchset.

Next time, please get Ack from TJ or Ben when you touch memblock code.
And at least make the TITLE is right.



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