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

From: Yinghai Lu
Date: Thu Feb 28 2013 - 11:07:12 EST

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.

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