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

[Yinghai Lu]

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.

as

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
memblock_find_in_range.

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.

Thanks

Yinghai
--
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/