linux-kernel - Re: [RFC v2 PATCH 2/8] mm: introduce MIGRATE

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: <55924AEF.4050107@jp.fujitsu.com>
Date:	Tue, 30 Jun 2015 16:53:19 +0900
From:	Kamezawa Hiroyuki <kamezawa.hiroyu@...fujitsu.com>
To:	Xishi Qiu <qiuxishi@...wei.com>
CC:	Andrew Morton <akpm@...ux-foundation.org>,
	"H. Peter Anvin" <hpa@...or.com>, Ingo Molnar <mingo@...nel.org>,
	"Luck, Tony" <tony.luck@...el.com>,
	Hanjun Guo <guohanjun@...wei.com>,
	Xiexiuqi <xiexiuqi@...wei.com>, leon@...n.nu,
	Dave Hansen <dave.hansen@...el.com>,
	Naoya Horiguchi <n-horiguchi@...jp.nec.com>,
	Vlastimil Babka <vbabka@...e.cz>, Mel Gorman <mgorman@...e.de>,
	Linux MM <linux-mm@...ck.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [RFC v2 PATCH 2/8] mm: introduce MIGRATE_MIRROR to manage the
 mirrored pages

On 2015/06/30 11:45, Xishi Qiu wrote:
> On 2015/6/29 15:32, Kamezawa Hiroyuki wrote:
>
>> On 2015/06/27 11:24, Xishi Qiu wrote:
>>> This patch introduces a new migratetype called "MIGRATE_MIRROR", it is used to
>>> allocate mirrored pages.
>>> When cat /proc/pagetypeinfo, you can see the count of free mirrored blocks.
>>>
>>> Signed-off-by: Xishi Qiu <qiuxishi@...wei.com>
>>
>> My fear about this approarch is that this may break something existing.
>>
>> Now, when we add MIGRATE_MIRROR type, we'll hide attributes of pageblocks as
>> MIGRATE_UNMOVABOLE, MIGRATE_RECLAIMABLE, MIGRATE_MOVABLE.
>>
>> Logically, MIRROR attribute is independent from page mobility and this overwrites
>> will make some information lost.
>>
>> Then,
>>
>>> ---
>>>    include/linux/mmzone.h | 9 +++++++++
>>>    mm/page_alloc.c        | 3 +++
>>>    mm/vmstat.c            | 3 +++
>>>    3 files changed, 15 insertions(+)
>>>
>>> diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
>>> index 54d74f6..54e891a 100644
>>> --- a/include/linux/mmzone.h
>>> +++ b/include/linux/mmzone.h
>>> @@ -39,6 +39,9 @@ enum {
>>>        MIGRATE_UNMOVABLE,
>>>        MIGRATE_RECLAIMABLE,
>>>        MIGRATE_MOVABLE,
>>> +#ifdef CONFIG_MEMORY_MIRROR
>>> +    MIGRATE_MIRROR,
>>> +#endif
>>
>> I think
>>          MIGRATE_MIRROR_UNMOVABLE,
>>          MIGRATE_MIRROR_RECLAIMABLE,
>>          MIGRATE_MIRROR_MOVABLE,         <== adding this may need discuss.
>>          MIGRATE_MIRROR_RESERVED,        <== reserved pages should be maintained per mirrored/unmirrored.
>>
>
> Hi Kame,
>
> You mean add 3 or 4 new migratetype?
>

yes. But please check how NR_MIGRATETYPE_BITS will be.
I think this will not have big impact in x86-64 .

>> should be added with the following fallback list.
>>
>> /*
>>   * MIRROR page range is defined by firmware at boot. The range is limited
>>   * and is used only for kernel memory mirroring.
>>   */
>> [MIGRATE_UNMOVABLE_MIRROR]   = {MIGRATE_RECLAIMABLE_MIRROR, MIGRATE_RESERVE}
>> [MIGRATE_RECLAIMABLE_MIRROR] = {MIGRATE_UNMOVABLE_MIRROR, MIGRATE_RESERVE}
>>
>
> Why not like this:
> {MIGRATE_RECLAIMABLE_MIRROR, MIGRATE_MIRROR_RESERVED, MIGRATE_RESERVE}
>

  My mistake.
[MIGRATE_UNMOVABLE_MIRROR]   = {MIGRATE_RECLAIMABLE_MIRROR, MIGRATE_RESERVE_MIRROR}
[MIGRATE_RECLAIMABLE_MIRROR] = {MIGRATE_UNMOVABLE_MIRROR, MIGRATE_RESERVE_MIRROR}

was my intention. This means mirrored memory and unmirrored memory is separated completely.

But this should affect kswapd or other memory reclaim logic.

for example, kswapd stops free pages are more than hi watermark.
But mirrored/unmirrored pages exhausted cases are not handled in this series.
You need some extra check in memory reclaim logic if you go with migration_type.



>> Then, we'll not lose the original information of "Reclaiable Pages".
>>
>> One problem here is whteher we should have MIGRATE_RESERVE_MIRROR.
>>
>> If we never allow users to allocate mirrored memory, we should have MIGRATE_RESERVE_MIRROR.
>> But it seems to require much more code change to do that.
>>
>> Creating a zone or adding an attribues to zones are another design choice.
>>
>
> If we add a new zone, mirror_zone will span others, I'm worry about this
> maybe have problems.

Yes. that's problem. And zoneid bit is very limited resource.
(....But memory reclaim logic can be unchanged.)

Anyway, I'd like to see your solution with above changes 1st rather than adding zones.

Thanks,
-Kame


--
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/