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