linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: "H. Peter Anvin" <hpa@zytor.com>
To: Tang Chen <tangchen@cn.fujitsu.com>,
	akpm@linux-foundation.org, jiang.liu@huawei.com,
	wujianguo@huawei.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
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [PATCH Bug fix] acpi, movablemem_map: node0 should always be unhotpluggable when using SRAT.
Date: Wed, 30 Jan 2013 07:55:11 -0800	[thread overview]
Message-ID: <6150ecbc-a720-4fd1-b32f-7338cc68445e@email.android.com> (raw)
In-Reply-To: <1359532470-28874-1-git-send-email-tangchen@cn.fujitsu.com>

It is not node 0, it is whatever node the kernel resides in.

Tang Chen <tangchen@cn.fujitsu.com> wrote:

>When using movablemem_map=acpi, always set node0 as unhotpluggable,
>otherwise
>if all the memory is hotpluggable, the kernel will fail to boot.
>
>When using movablemem_map=nn[KMG]@ss[KMG], we don't stop users
>specifying
>node0 as hotpluggable, and ignore all the info in SRAT, so that this
>option
>can be used as a workaround of firmware bugs.
>
>Reported-by: H. Peter Anvin <hpa@zytor.com>
>Signed-off-by: Tang Chen <tangchen@cn.fujitsu.com>
>---
> Documentation/kernel-parameters.txt |    6 ++++++
> arch/x86/mm/srat.c                  |   10 ++++++++--
> 2 files changed, 14 insertions(+), 2 deletions(-)
>
>diff --git a/Documentation/kernel-parameters.txt
>b/Documentation/kernel-parameters.txt
>index 7d1b6fc..81b6f15 100644
>--- a/Documentation/kernel-parameters.txt
>+++ b/Documentation/kernel-parameters.txt
>@@ -1645,6 +1645,8 @@ bytes respectively. Such letter suffixes can also
>be entirely omitted.
> 			in flags from SRAT from ACPI BIOS to determine which
> 			memory devices could be hotplugged. The corresponding
> 			memory ranges will be set as ZONE_MOVABLE.
>+			NOTE: node0 should always be unhotpluggable, otherwise
>+			      the kernel will fail to boot.
> 
> 	movablemem_map=nn[KMG]@ss[KMG]
> 			[KNL,X86,IA-64,PPC] This parameter is similar to
>@@ -1666,6 +1668,10 @@ bytes respectively. Such letter suffixes can
>also be entirely omitted.
> 			satisfied. So the administrator should be careful that
> 			the amount of movablemem_map areas are not too large.
> 			Otherwise kernel won't have enough memory to start.
>+			NOTE: We don't stop users specifying node0 as
>+			      hotpluggable, and ingore all the info in SRAT so
>+			      that this option can be used as a workaround of
>+			      firmware bugs.
> 
> 	MTD_Partition=	[MTD]
> 			Format: <name>,<region-number>,<size>,<offset>
>diff --git a/arch/x86/mm/srat.c b/arch/x86/mm/srat.c
>index b20b5b7..a85d2b7 100644
>--- a/arch/x86/mm/srat.c
>+++ b/arch/x86/mm/srat.c
>@@ -161,9 +161,13 @@ 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.
>+	 *
>+	 * NOTE: node0 shoule always be unhotpluggable, otherwise, if all the
>+	 *       memory is hotpluggable, there will be no memory kernel can
>use.
> 	 */
> 	if (hotpluggable && movablemem_map.acpi) {
>-		insert_movablemem_map(start_pfn, end_pfn);
>+		if (node != 0)
>+			insert_movablemem_map(start_pfn, end_pfn);
> 		goto out;
> 	}
> 
>@@ -178,7 +182,9 @@ 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.
> 	 *
>-	 * NOTE: In this case, SRAT info will be ingored.
>+	 * NOTE: We don't stop users specifying node0 as hotpluggable, and
>+	 *       ignore all the info in SRAT, so that this option can be used
>+	 *       as a workaround of firmware bugs.
> 	 */
> 	overlap = movablemem_map_overlap(start_pfn, end_pfn);
> 	if (overlap >= 0) {

-- 
Sent from my mobile phone. Please excuse brevity and lack of formatting.

--
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: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

      parent reply	other threads:[~2013-01-30 15:55 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-30  7:54 Tang Chen
2013-01-30  8:50 ` David Rientjes
2013-01-30  9:05   ` Tang Chen
2013-01-30  9:45     ` David Rientjes
2013-01-30 10:32       ` Tang Chen
2013-01-30 22:48         ` David Rientjes
2013-01-30 15:55 ` H. Peter Anvin [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=6150ecbc-a720-4fd1-b32f-7338cc68445e@email.android.com \
    --to=hpa@zytor.com \
    --cc=akpm@linux-foundation.org \
    --cc=glommer@parallels.com \
    --cc=guz.fnst@cn.fujitsu.com \
    --cc=isimatu.yasuaki@jp.fujitsu.com \
    --cc=jaegeuk.hanse@gmail.com \
    --cc=jiang.liu@huawei.com \
    --cc=kosaki.motohiro@jp.fujitsu.com \
    --cc=laijs@cn.fujitsu.com \
    --cc=linfeng@cn.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=lliubbo@gmail.com \
    --cc=mgorman@suse.de \
    --cc=minchan.kim@gmail.com \
    --cc=rientjes@google.com \
    --cc=rob@landley.net \
    --cc=rusty@rustcorp.com.au \
    --cc=tangchen@cn.fujitsu.com \
    --cc=tony.luck@intel.com \
    --cc=wency@cn.fujitsu.com \
    --cc=wujianguo@huawei.com \
    --cc=yinghai@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox