From: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
To: Tang Chen <tangchen@cn.fujitsu.com>
Cc: jiang.liu@huawei.com, wujianguo@huawei.com, hpa@zytor.com,
akpm@linux-foundation.org, wency@cn.fujitsu.com,
laijs@cn.fujitsu.com, linfeng@cn.fujitsu.com, yinghai@kernel.org,
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
Subject: Re: [PATCH v4 3/6] ACPI: Restructure movablecore_map with memory info from SRAT.
Date: Wed, 26 Dec 2012 15:53:09 +0900 [thread overview]
Message-ID: <50DA9ED5.4000501@jp.fujitsu.com> (raw)
In-Reply-To: <1355908308-24744-1-git-send-email-tangchen@cn.fujitsu.com>
Hi Tang,
I don't think it can work well.
The patch gets memory range of hotpluggable memory by
acpi_numa_memory_affinity_init(). But it too late.
For example, if we use log_buf_len boot options, memblock allocator
runs before getting SRAT information. In this case, this movablecore_map
boot option does not work well.
Thanks,
Yasuaki Ishimatsu
2012/12/19 18:11, Tang Chen wrote:
> The Hot Plugable bit in SRAT flags specifys if the memory range
> could be hotplugged.
>
> If user specified movablecore_map=nn[KMG]@ss[KMG], reset
> movablecore_map.map to the intersection of hotpluggable ranges from
> SRAT and old movablecore_map.map.
> Else if user specified movablecore_map=acpi, just use the hotpluggable
> ranges from SRAT.
> Otherwise, do nothing. The kernel will use all the memory in all nodes
> evenly.
>
> The idea "getting info from SRAT" was from Liu Jiang <jiang.liu@huawei.com>.
> And the idea "do more limit for memblock" was from Wu Jianguo <wujianguo@huawei.com>
>
> Signed-off-by: Tang Chen <tangchen@cn.fujitsu.com>
> Tested-by: Gu Zheng <guz.fnst@cn.fujitsu.com>
> ---
> arch/x86/mm/srat.c | 55 +++++++++++++++++++++++++++++++++++++++++++++++++--
> 1 files changed, 52 insertions(+), 3 deletions(-)
>
> diff --git a/arch/x86/mm/srat.c b/arch/x86/mm/srat.c
> index 4ddf497..a8856d2 100644
> --- a/arch/x86/mm/srat.c
> +++ b/arch/x86/mm/srat.c
> @@ -146,7 +146,12 @@ int __init
> acpi_numa_memory_affinity_init(struct acpi_srat_mem_affinity *ma)
> {
> u64 start, end;
> + u32 hotpluggable;
> int node, pxm;
> +#ifdef CONFIG_HAVE_MEMBLOCK_NODE_MAP
> + int overlap;
> + unsigned long start_pfn, end_pfn;
> +#endif /* CONFIG_HAVE_MEMBLOCK_NODE_MAP */
>
> if (srat_disabled())
> return -1;
> @@ -157,8 +162,10 @@ acpi_numa_memory_affinity_init(struct acpi_srat_mem_affinity *ma)
> if ((ma->flags & ACPI_SRAT_MEM_ENABLED) == 0)
> return -1;
>
> - if ((ma->flags & ACPI_SRAT_MEM_HOT_PLUGGABLE) && !save_add_info())
> + hotpluggable = ma->flags & ACPI_SRAT_MEM_HOT_PLUGGABLE;
> + if (hotpluggable && !save_add_info())
> return -1;
> +
> start = ma->base_address;
> end = start + ma->length;
> pxm = ma->proximity_domain;
> @@ -178,9 +185,51 @@ acpi_numa_memory_affinity_init(struct acpi_srat_mem_affinity *ma)
>
> node_set(node, numa_nodes_parsed);
>
> - printk(KERN_INFO "SRAT: Node %u PXM %u [mem %#010Lx-%#010Lx]\n",
> + printk(KERN_INFO "SRAT: Node %u PXM %u [mem %#010Lx-%#010Lx] %s\n",
> node, pxm,
> - (unsigned long long) start, (unsigned long long) end - 1);
> + (unsigned long long) start, (unsigned long long) end - 1,
> + hotpluggable ? "Hot Pluggable": "");
> +
> +#ifdef CONFIG_HAVE_MEMBLOCK_NODE_MAP
> + start_pfn = PFN_DOWN(start);
> + end_pfn = PFN_UP(end);
> +
> + if (!hotpluggable) {
> + /* Clear the range overlapped in movablecore_map.map */
> + remove_movablecore_map(start_pfn, end_pfn);
> + goto out;
> + }
> +
> + if (!movablecore_map.acpi) {
> + for (overlap = 0; overlap < movablecore_map.nr_map; overlap++) {
> + if (start_pfn < movablecore_map.map[overlap].end_pfn)
> + break;
> + }
> +
> + /*
> + * If there is no overlapped range, or the end of the overlapped
> + * range is higher than end_pfn, then insert nothing.
> + */
> + if (end_pfn <= movablecore_map.map[overlap].end_pfn)
> + goto out;
> +
> + /*
> + * Otherwise, insert the rest of this range to prevent memblock
> + * from allocating memory in it.
> + */
> + start_pfn = movablecore_map.map[overlap].end_pfn;
> + start = start_pfn >> PAGE_SHIFT;
> + }
> +
> + /* If user chose to use SRAT info, insert the range anyway. */
> + if (insert_movablecore_map(start_pfn, end_pfn))
> + pr_err("movablecore_map: too many entries;"
> + " ignoring [mem %#010llx-%#010llx]\n",
> + (unsigned long long) start,
> + (unsigned long long) (end - 1));
> +
> +out:
> +#endif /* CONFIG_HAVE_MEMBLOCK_NODE_MAP */
> return 0;
> }
>
>
--
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>
WARNING: multiple messages have this Message-ID (diff)
From: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
To: Tang Chen <tangchen@cn.fujitsu.com>
Cc: <jiang.liu@huawei.com>, <wujianguo@huawei.com>, <hpa@zytor.com>,
<akpm@linux-foundation.org>, <wency@cn.fujitsu.com>,
<laijs@cn.fujitsu.com>, <linfeng@cn.fujitsu.com>,
<yinghai@kernel.org>, <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>
Subject: Re: [PATCH v4 3/6] ACPI: Restructure movablecore_map with memory info from SRAT.
Date: Wed, 26 Dec 2012 15:53:09 +0900 [thread overview]
Message-ID: <50DA9ED5.4000501@jp.fujitsu.com> (raw)
In-Reply-To: <1355908308-24744-1-git-send-email-tangchen@cn.fujitsu.com>
Hi Tang,
I don't think it can work well.
The patch gets memory range of hotpluggable memory by
acpi_numa_memory_affinity_init(). But it too late.
For example, if we use log_buf_len boot options, memblock allocator
runs before getting SRAT information. In this case, this movablecore_map
boot option does not work well.
Thanks,
Yasuaki Ishimatsu
2012/12/19 18:11, Tang Chen wrote:
> The Hot Plugable bit in SRAT flags specifys if the memory range
> could be hotplugged.
>
> If user specified movablecore_map=nn[KMG]@ss[KMG], reset
> movablecore_map.map to the intersection of hotpluggable ranges from
> SRAT and old movablecore_map.map.
> Else if user specified movablecore_map=acpi, just use the hotpluggable
> ranges from SRAT.
> Otherwise, do nothing. The kernel will use all the memory in all nodes
> evenly.
>
> The idea "getting info from SRAT" was from Liu Jiang <jiang.liu@huawei.com>.
> And the idea "do more limit for memblock" was from Wu Jianguo <wujianguo@huawei.com>
>
> Signed-off-by: Tang Chen <tangchen@cn.fujitsu.com>
> Tested-by: Gu Zheng <guz.fnst@cn.fujitsu.com>
> ---
> arch/x86/mm/srat.c | 55 +++++++++++++++++++++++++++++++++++++++++++++++++--
> 1 files changed, 52 insertions(+), 3 deletions(-)
>
> diff --git a/arch/x86/mm/srat.c b/arch/x86/mm/srat.c
> index 4ddf497..a8856d2 100644
> --- a/arch/x86/mm/srat.c
> +++ b/arch/x86/mm/srat.c
> @@ -146,7 +146,12 @@ int __init
> acpi_numa_memory_affinity_init(struct acpi_srat_mem_affinity *ma)
> {
> u64 start, end;
> + u32 hotpluggable;
> int node, pxm;
> +#ifdef CONFIG_HAVE_MEMBLOCK_NODE_MAP
> + int overlap;
> + unsigned long start_pfn, end_pfn;
> +#endif /* CONFIG_HAVE_MEMBLOCK_NODE_MAP */
>
> if (srat_disabled())
> return -1;
> @@ -157,8 +162,10 @@ acpi_numa_memory_affinity_init(struct acpi_srat_mem_affinity *ma)
> if ((ma->flags & ACPI_SRAT_MEM_ENABLED) == 0)
> return -1;
>
> - if ((ma->flags & ACPI_SRAT_MEM_HOT_PLUGGABLE) && !save_add_info())
> + hotpluggable = ma->flags & ACPI_SRAT_MEM_HOT_PLUGGABLE;
> + if (hotpluggable && !save_add_info())
> return -1;
> +
> start = ma->base_address;
> end = start + ma->length;
> pxm = ma->proximity_domain;
> @@ -178,9 +185,51 @@ acpi_numa_memory_affinity_init(struct acpi_srat_mem_affinity *ma)
>
> node_set(node, numa_nodes_parsed);
>
> - printk(KERN_INFO "SRAT: Node %u PXM %u [mem %#010Lx-%#010Lx]\n",
> + printk(KERN_INFO "SRAT: Node %u PXM %u [mem %#010Lx-%#010Lx] %s\n",
> node, pxm,
> - (unsigned long long) start, (unsigned long long) end - 1);
> + (unsigned long long) start, (unsigned long long) end - 1,
> + hotpluggable ? "Hot Pluggable": "");
> +
> +#ifdef CONFIG_HAVE_MEMBLOCK_NODE_MAP
> + start_pfn = PFN_DOWN(start);
> + end_pfn = PFN_UP(end);
> +
> + if (!hotpluggable) {
> + /* Clear the range overlapped in movablecore_map.map */
> + remove_movablecore_map(start_pfn, end_pfn);
> + goto out;
> + }
> +
> + if (!movablecore_map.acpi) {
> + for (overlap = 0; overlap < movablecore_map.nr_map; overlap++) {
> + if (start_pfn < movablecore_map.map[overlap].end_pfn)
> + break;
> + }
> +
> + /*
> + * If there is no overlapped range, or the end of the overlapped
> + * range is higher than end_pfn, then insert nothing.
> + */
> + if (end_pfn <= movablecore_map.map[overlap].end_pfn)
> + goto out;
> +
> + /*
> + * Otherwise, insert the rest of this range to prevent memblock
> + * from allocating memory in it.
> + */
> + start_pfn = movablecore_map.map[overlap].end_pfn;
> + start = start_pfn >> PAGE_SHIFT;
> + }
> +
> + /* If user chose to use SRAT info, insert the range anyway. */
> + if (insert_movablecore_map(start_pfn, end_pfn))
> + pr_err("movablecore_map: too many entries;"
> + " ignoring [mem %#010llx-%#010llx]\n",
> + (unsigned long long) start,
> + (unsigned long long) (end - 1));
> +
> +out:
> +#endif /* CONFIG_HAVE_MEMBLOCK_NODE_MAP */
> return 0;
> }
>
>
next prev parent reply other threads:[~2012-12-26 6:54 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-12-19 8:14 [PATCH v4 0/6] Add movablecore_map boot option with SRAT support Tang Chen
2012-12-19 8:14 ` Tang Chen
2012-12-19 8:14 ` [PATCH v4 1/6] x86: get pg_data_t's memory from other node Tang Chen
2012-12-19 8:14 ` Tang Chen
2012-12-19 8:14 ` [PATCH v4 2/6] page_alloc: add movablecore_map kernel parameter Tang Chen
2012-12-19 8:14 ` Tang Chen
2012-12-19 8:15 ` [PATCH v4 3/6] ACPI: Restructure movablecore_map with memory info from SRAT Tang Chen
2012-12-19 8:15 ` Tang Chen
2012-12-19 9:11 ` Tang Chen
2012-12-19 9:11 ` Tang Chen
2012-12-26 6:53 ` Yasuaki Ishimatsu [this message]
2012-12-26 6:53 ` Yasuaki Ishimatsu
2012-12-26 7:39 ` Tang Chen
2012-12-26 7:39 ` Tang Chen
2012-12-26 8:33 ` Yasuaki Ishimatsu
2012-12-26 8:33 ` Yasuaki Ishimatsu
2012-12-19 9:15 ` Tang Chen
2012-12-19 9:15 ` Tang Chen
2012-12-19 8:15 ` [PATCH v4 4/6] page_alloc: Introduce zone_movable_limit[] to keep movable limit for nodes Tang Chen
2012-12-19 8:15 ` Tang Chen
2012-12-19 8:15 ` [PATCH v4 5/6] page_alloc: Make movablecore_map has higher priority Tang Chen
2012-12-19 8:15 ` Tang Chen
2012-12-19 8:15 ` [PATCH v4 6/6] page_alloc: Bootmem limit with movablecore_map Tang Chen
2012-12-19 8:15 ` Tang Chen
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=50DA9ED5.4000501@jp.fujitsu.com \
--to=isimatu.yasuaki@jp.fujitsu.com \
--cc=akpm@linux-foundation.org \
--cc=glommer@parallels.com \
--cc=guz.fnst@cn.fujitsu.com \
--cc=hpa@zytor.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.