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] [day] [month] [year] [list]

Message-ID: <5130694E.6020009@jp.fujitsu.com>
Date:	Fri, 1 Mar 2013 17:39:42 +0900
From:	Yasuaki Ishimatsu <isimatu.yasuaki@...fujitsu.com>
To:	Yinghai Lu <yinghai@...nel.org>
CC:	Tang Chen <tangchen@...fujitsu.com>,
	"H. Peter Anvin" <hpa@...or.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Lai Jiangshan <laijs@...fujitsu.com>,
	Don Morris <don.morris@...com>,
	Tim Gardner <tim.gardner@...onical.com>,
	Tejun Heo <tj@...nel.org>, Tony Luck <tony.luck@...el.com>,
	Thomas Renninger <trenn@...e.de>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Jarkko Sakkinen <jarkko.sakkinen@...el.com>,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	Wen Congyang <wency@...fujitsu.com>,
	Lin Feng <linfeng@...fujitsu.com>,
	"guz.fnst@...fujitsu.com" <guz.fnst@...fujitsu.com>,
	Gui jianfeng <guijianfeng@...fujitsu.com>
Subject: Re: sched: CPU #1's llc-sibling CPU #0 is not on the same node!

2013/03/01 17:02, Yinghai Lu wrote:
> On Thu, Feb 28, 2013 at 10:18 PM, Tang Chen <tangchen@...fujitsu.com> wrote:
>> On 03/01/2013 01:00 PM, Yinghai Lu wrote:
>>>
>>> On Thursday, February 28, 2013, H. Peter Anvin wrote:
>>>
>>>> On 02/28/2013 08:32 PM, Linus Torvalds wrote:
>>>>>
>>>>> Yingai, Andrew,
>>>>>    is this ok with you two?
>>>>>
>>>>>           Linus
>>>>
>>>>
>>>> FWIW, it makes sense to me iff it resolves the problems
>>>
>>>
>>>
>>> I prefer to reverting all 8 patches.
>>>
>>> Actually I have worked out one patch that could solve all problems, but it
>>> is too intrusive that I do      not want to split it to small pieces to
>>> post it.
>>>
>>> Leaving the movablemem_map related changes in  the upstream tree,
>>> will prevent me from continuing to make memblock to be used to allocate
>>> page table on local node ram for hot add.
>>
>>
>> Hi Yinghai,
>>
>> Would you please give me a url to your code ?
>>
>> I don't think movablemem_map will block your work a lot. According to your
>> description, you are modifying memblock to reserve some memory for local
>> node pagetables, right ?
>

> My idea:
> current for hotadd mem, page table will from other nodes from slub.
> that is not right. that will prevent others nodes to be hot removed.

If we use your idea, pglist_data and zone are also allocated from local
node. In my understanding, pglist_data and zone cannot be deleted safely
since there is no way to guarantee that nobody use them. So it means
that all nodes cannot be hot removed.
If you develop your idea, you should consider memory hot remove.

Thanks,
Yasuaki Ishimatsu

>
> To fix the problem
> a. make memblock still alive after booting.
> b. or have separated dynamical memblock.
>
> second way looks more clean.
> so alloc_low_pages will get initial page for page table from low range
> with slub.
> and later will get page table from its own just mapped range.
>
> Now need to make memblock more clean and remove hardcoded reference in
> those functions.
>
> 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/