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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 01 Mar 2013 09:39:57 +0800
From:	Tang Chen <tangchen@...fujitsu.com>
To:	Yinghai Lu <yinghai@...nel.org>
CC:	Andrew Morton <akpm@...ux-foundation.org>,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	Tejun Heo <tj@...nel.org>,
	Yasuaki Ishimatsu <isimatu.yasuaki@...fujitsu.com>,
	Don Morris <don.morris@...com>,
	Tim Gardner <tim.gardner@...onical.com>,
	"H. Peter Anvin" <hpa@...or.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Tony Luck <tony.luck@...el.com>,
	Thomas Renninger <trenn@...e.de>, linux-kernel@...r.kernel.org,
	tglx@...utronix.de, mingo@...hat.com, a.p.zijlstra@...llo.nl,
	jarkko.sakkinen@...el.com
Subject: Re: sched: CPU #1's llc-sibling CPU #0 is not on the same node!

On 03/01/2013 12:07 AM, Yinghai Lu wrote:
> On Tue, Feb 26, 2013 at 11:44 PM, Tang Chen<tangchen@...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@...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.

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.
>
> Thanks
>
> Yinghai
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/