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]

Message-ID: <CAE9FiQWAxL6F70fF0dQcBZKTReJOiC+Ez0xcqcosgAdSagS-bA@mail.gmail.com>
Date:	Tue, 26 Feb 2013 21:11:26 -0800
From:	Yinghai Lu <yinghai@...nel.org>
To:	Andrew Morton <akpm@...ux-foundation.org>,
	Yasuaki Ishimatsu <isimatu.yasuaki@...fujitsu.com>,
	Tang Chen <tangchen@...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>
Cc:	Tejun Heo <tj@...nel.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 Tue, Feb 26, 2013 at 8:43 PM, Yasuaki Ishimatsu
<isimatu.yasuaki@...fujitsu.com> wrote:
> 2013/02/27 13:04, Yinghai Lu wrote:
>>
>> On Tue, Feb 26, 2013 at 7:38 PM, Yasuaki Ishimatsu
>> <isimatu.yasuaki@...fujitsu.com> wrote:
>>>
>>> 2013/02/27 11:30, Yinghai Lu wrote:
>>>>
>>>> Do you mean you can not boot one socket system with 1G ram ?
>>>> Assume socket 0 does not support hotplug, other 31 sockets support hot
>>>> plug.
>>>>
>>>> So we could boot system only with socket0, and later one by one hot
>>>> add other cpus.
>>>
>>>
>>>
>>> In this case, system can boot. But other cpus with bunch of ram hot
>>> plug may fails, since system does not have enough memory for cover
>>> hot added memory. When hot adding memory device, kernel object for the
>>> memory is allocated from 1G ram since hot added memory has not been
>>> enabled.
>>>
>>
>> yes, it may fail, if the one node memory need page table and vmemmap
>> is more than 1g ...
>>
>
>> for hot add memory we need to
>> 1. add another wrapper for init_memory_mapping, just like
>> init_mem_mapping() for booting path.
>> 2. we need make memblock more generic, so we can use it with hot add
>> memory during runtime.
>> 3. with that we can initialize page table for hot added node with ram.
>> a. initial page table for 2M near node top is from node0 ( that does
>> not support hot plug).
>> b. then will use 2M for memory below node top...
>> c. with that we will make sure page table stay on local node.
>>   alloc_low_pages need to be updated to support that.
>> 4. need to make sure vmemmap on local node too.
>
>
> I think so too. By this, memory hot plug becomes more useful.
>
>>
>> so hot-remove node will work too later.
>>
>> In the long run, we should make booting path and hot adding more
>> similar and share at most code.
>> That will make code get more test coverage.

Tang,  Yasuaki, Andrew,

Please check if you are ok with attached reverting patch.

Tim, Don,
Can you try if attached reverting patch fix all the problems for you ?

Thanks

Yinghai

Download attachment "revert_movable_map.patch" of type "application/octet-stream" (31559 bytes)