Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750821AbbF3HyC (ORCPT ); Tue, 30 Jun 2015 03:54:02 -0400 Received: from mgwkm04.jp.fujitsu.com ([202.219.69.171]:55127 "EHLO mgwkm04.jp.fujitsu.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750800AbbF3Hxx (ORCPT ); Tue, 30 Jun 2015 03:53:53 -0400 X-SecurityPolicyCheck: OK by SHieldMailChecker v2.3.2 X-SHieldMailCheckerPolicyVersion: FJ-ISEC-20150223 X-SHieldMailCheckerMailID: a050b766c97d47e7a204c4f6f9c54bbd Message-ID: <55924AEF.4050107@jp.fujitsu.com> Date: Tue, 30 Jun 2015 16:53:19 +0900 From: Kamezawa Hiroyuki User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Xishi Qiu CC: Andrew Morton , "H. Peter Anvin" , Ingo Molnar , "Luck, Tony" , Hanjun Guo , Xiexiuqi , leon@leon.nu, Dave Hansen , Naoya Horiguchi , Vlastimil Babka , Mel Gorman , Linux MM , LKML Subject: Re: [RFC v2 PATCH 2/8] mm: introduce MIGRATE_MIRROR to manage the mirrored pages References: <558E084A.60900@huawei.com> <558E0948.2010104@huawei.com> <5590F4A7.4030606@jp.fujitsu.com> <559202E2.8060609@huawei.com> In-Reply-To: <559202E2.8060609@huawei.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-TM-AS-MML: disable Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3682 Lines: 108 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 >> >> 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/