From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from psmtp.com (na3sys010amx167.postini.com [74.125.245.167]) by kanga.kvack.org (Postfix) with SMTP id 338C46B0002 for ; Wed, 20 Feb 2013 07:36:10 -0500 (EST) Received: by mail-qe0-f44.google.com with SMTP id a11so3661927qen.3 for ; Wed, 20 Feb 2013 04:36:09 -0800 (PST) Message-ID: <5124C32E.1080902@gmail.com> Date: Wed, 20 Feb 2013 20:35:58 +0800 From: Will Huck MIME-Version: 1.0 Subject: Re: [Bug fix PATCH 1/2] acpi, movablemem_map: Exclude memblock.reserved ranges when parsing SRAT. References: <1361358056-1793-1-git-send-email-tangchen@cn.fujitsu.com> <1361358056-1793-2-git-send-email-tangchen@cn.fujitsu.com> <5124C22B.8030401@cn.fujitsu.com> In-Reply-To: <5124C22B.8030401@cn.fujitsu.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Tang Chen Cc: akpm@linux-foundation.org, jiang.liu@huawei.com, wujianguo@huawei.com, hpa@zytor.com, wency@cn.fujitsu.com, laijs@cn.fujitsu.com, linfeng@cn.fujitsu.com, yinghai@kernel.org, isimatu.yasuaki@jp.fujitsu.com, rob@landley.net, kosaki.motohiro@jp.fujitsu.com, minchan.kim@gmail.com, mgorman@suse.de, rientjes@google.com, guz.fnst@cn.fujitsu.com, rusty@rustcorp.com.au, lliubbo@gmail.com, jaegeuk.hanse@gmail.com, tony.luck@intel.com, glommer@parallels.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org On 02/20/2013 08:31 PM, Tang Chen wrote: > On 02/20/2013 07:00 PM, Tang Chen wrote: >> As mentioned by HPA before, when we are using movablemem_map=acpi, if >> all the >> memory ranges in SRAT is hotpluggable, then no memory can be used by >> kernel. >> >> Before parsing SRAT, memblock has already reserve some memory ranges >> for other >> purposes, such as for kernel image, and so on. We cannot prevent >> kernel from >> using these memory. So we need to exclude these ranges even if these >> memory is >> hotpluggable. >> >> This patch changes the movablemem_map=acpi option's behavior. The >> memory ranges >> reserved by memblock will not be added into movablemem_map.map[]. So >> even if >> all the memory is hotpluggable, there will always be memory that >> could be used >> by the kernel. >> What's the relationship between e820 map and SRAT? >> Reported-by: H Peter Anvin >> Signed-off-by: Tang Chen >> --- >> arch/x86/mm/srat.c | 18 +++++++++++++++++- >> 1 files changed, 17 insertions(+), 1 deletions(-) >> >> diff --git a/arch/x86/mm/srat.c b/arch/x86/mm/srat.c >> index 62ba97b..b8028b2 100644 >> --- a/arch/x86/mm/srat.c >> +++ b/arch/x86/mm/srat.c >> @@ -145,7 +145,7 @@ static inline int save_add_info(void) {return 0;} >> static void __init >> handle_movablemem(int node, u64 start, u64 end, u32 hotpluggable) >> { >> - int overlap; >> + int overlap, i; >> unsigned long start_pfn, end_pfn; >> >> start_pfn = PFN_DOWN(start); >> @@ -161,8 +161,24 @@ handle_movablemem(int node, u64 start, u64 end, >> u32 hotpluggable) >> * >> * Using movablemem_map, we can prevent memblock from >> allocating memory >> * on ZONE_MOVABLE at boot time. >> + * >> + * Before parsing SRAT, memblock has already reserve some memory >> ranges >> + * for other purposes, such as for kernel image. We cannot prevent >> + * kernel from using these memory, so we need to exclude these >> memory >> + * even if it is hotpluggable. >> */ >> if (hotpluggable&& movablemem_map.acpi) { >> + /* Exclude ranges reserved by memblock. */ >> + struct memblock_type *rgn =&memblock.reserved; >> + >> + for (i = 0; i< rgn->cnt; i++) { >> + if (end<= rgn->regions[i].base || >> + start>= rgn->regions[i].base + >> + rgn->regions[i].size) > > Hi all, > > Here, I scan the memblock.reserved each time we parse an entry because > the > rgn->regions[i].nid is set to MAX_NUMNODES in memblock_reserve(). So I > cannot > obtain the nid which the kernel resides in directly from > memblock.reserved. > > I think there could be some problems if the memory ranges in SRAT are > not in > increasing order, since if [3,4) [1,2) are all on node0, and kernel is > not > using [3,4), but using [1,2), then I cannot remove [3,4) because I > don't know > on which node [3,4) is. > > Any idea for this ? > > And by the way, I think this approach works well when the memory > entries in > SRAT are arranged in increasing order. > > Thanks. :) > >> + continue; >> + goto out; >> + } >> + >> insert_movablemem_map(start_pfn, end_pfn); >> >> /* > > -- > To unsubscribe, send a message with 'unsubscribe linux-mm' in > the body to majordomo@kvack.org. For more info on Linux MM, > see: http://www.linux-mm.org/ . > Don't email: email@kvack.org -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org