linux-kernel - Re: [PATCH v4 00/22] x86, ACPI, numa: Parse numa info early

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: <5191FEA7.7060606@cn.fujitsu.com>
Date:	Tue, 14 May 2013 17:06:47 +0800
From:	Tang Chen <tangchen@...fujitsu.com>
To:	Yinghai Lu <yinghai@...nel.org>
CC:	Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...e.hu>,
	"H. Peter Anvin" <hpa@...or.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Tejun Heo <tj@...nel.org>, Thomas Renninger <trenn@...e.de>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Yasuaki Ishimatsu <isimatu.yasuaki@...fujitsu.com>
Subject: Re: [PATCH v4 00/22] x86, ACPI, numa: Parse numa info early

Hi Yinghai,

How do you think of the following problem and solutions ?

And can we not allocate pagetable to local node when MEMORY_HOTREMOVE
is enabled for now, and do it again when the problem in hot-remove
path is fixed ?

Thanks. :)

On 05/13/2013 10:59 AM, Tang Chen wrote:
> Hi Yinghai,
>
> On 05/10/2013 02:24 AM, Yinghai Lu wrote:
>>>> So I suggest to separate the job into 2 parts:
>>>> 1. Push Yinghai's patch1 ~ patch20, without putting pagetable in local
>>>> node.
>>>> And push my work to use SRAT to arrange ZONE_MOVABLE.
>>>> In this case, we can enable memory hotplug in the kernel first.
>>>> 2. Merge patch21 and patch22 into the fixing work I am doing now,
>>>> and push
>>>> them
>>>> together when finished.
>>>>
>>
>> no, no, no, please do not half-done work.
>>
>> Do it right, and Do it clean.
>>
>
> I'm not saying I want to do it half-way. Putting pagetable in local node
> will make memory hot-remove patch unable to work.
>
> Before removing pages, the kernel first offlines pages. If the offline
> logic
> fails, the hot-remove cannot work. Since your patches have put node
> pagetable
> in local node at boot time, this memory cannot be offlined, furthermore,
> it cannot be hot-removed.
>
> The minimum unit of memory online/offline is block. And by default,
> one block contains one section, which by default is 128MB. So if parts
> of a block are pagetable, and the rest parts are movable memory, this
> block cannot be offlined. And as a result, it cannot be removed.
>
> In order to fix it, we have three solutions:
>
> 1. Reserve the whole block (128MB), making no user can use the rest
> parts of the block. And skip them when offlining memory.
> When all the other blocks are offlined, free the pagetable, and remove
> all the memory.
>
> But we may lose some memory for this purpose. 128MB is a little big
> to waste.
>
>
> 2. Migrate movable pages and keep this block online. Although the offline
> operation fails, it is OK to remove memory.
>
> But the offline operation will always fail. And generally speaking,
> there are a lot of reasons of offline failing, it is difficult to
> detect if it is OK to remove memory.
>
>
> 3. Migrate user pages and make this block offline, but the kernel can
> still use the pagetable in it.
>
> But this will change the semantics of "offline". I'm not sure if we
> can do it in this way.
>
>
> 4. Do not allocate pagetable to local node when CONFIG_MEMORY_HOTREMOVE
> is enabled. (I do suggest not to put pagetable in local node in
> memory hot-remove situation.)
>
>
> How do you think about these 4 solutions above ?
>
> I think I need some advices for this problem in community. Do you have
> any idea to fix this problem if we put pagetable in local node ?
>
> The memory hot-plug guys do want to use memory hot-remove. And I think
> for now, we use solution 4 above. When CONFIG_MEMORY_HOTREMOVE is enabled,
> do not allocate pagetable to local node.
>
> I'm not trying to do it half-way. When we fix this problem, we can allocate
> pagetable to local node again with CONFIG_MEMORY_HOTREMOVE enabled.
>
> Please do give some advices or feedback.
>
>
>>>
>>> If you have any thinking of this patch-set, please let me know.
>>
>> Talked to HPA, and he will put my patchset into tip/x86/mm after
>> v3.10-rc1.
>>
>> after that we can work on put pagetable on local node for hotadd path.
>>
>
> hot-add path is another problem. But I think the hot-remove path is more
> urgent now.
>
>
> Thanks. :)
> --
> 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/
>
--
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/