lkml.org 
[lkml]   [2013]   [Feb]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: sched: CPU #1's llc-sibling CPU #0 is not on the same node!
From
On Tue, Feb 26, 2013 at 11:44 PM, Tang Chen <tangchen@cn.fujitsu.com> 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@cn.fujitsu.com>
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


\
 
 \ /
  Last update: 2013-02-28 17:41    [W:0.069 / U:5.664 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site