From: Tang Chen <tangchen@cn.fujitsu.com>
To: 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
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [Bug fix PATCH 1/2] acpi, movablemem_map: Exclude memblock.reserved ranges when parsing SRAT.
Date: Wed, 20 Feb 2013 20:31:39 +0800 [thread overview]
Message-ID: <5124C22B.8030401@cn.fujitsu.com> (raw)
In-Reply-To: <1361358056-1793-2-git-send-email-tangchen@cn.fujitsu.com>
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.
>
> Reported-by: H Peter Anvin<hpa@zytor.com>
> Signed-off-by: Tang Chen<tangchen@cn.fujitsu.com>
> ---
> 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: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
WARNING: multiple messages have this Message-ID (diff)
From: Tang Chen <tangchen@cn.fujitsu.com>
To: 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
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [Bug fix PATCH 1/2] acpi, movablemem_map: Exclude memblock.reserved ranges when parsing SRAT.
Date: Wed, 20 Feb 2013 20:31:39 +0800 [thread overview]
Message-ID: <5124C22B.8030401@cn.fujitsu.com> (raw)
In-Reply-To: <1361358056-1793-2-git-send-email-tangchen@cn.fujitsu.com>
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.
>
> Reported-by: H Peter Anvin<hpa@zytor.com>
> Signed-off-by: Tang Chen<tangchen@cn.fujitsu.com>
> ---
> 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);
>
> /*
next prev parent reply other threads:[~2013-02-20 12:32 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-20 11:00 [Bug fix PATCH 0/2] Make whatever node kernel resides in un-hotpluggable Tang Chen
2013-02-20 11:00 ` Tang Chen
2013-02-20 11:00 ` [Bug fix PATCH 1/2] acpi, movablemem_map: Exclude memblock.reserved ranges when parsing SRAT Tang Chen
2013-02-20 11:00 ` Tang Chen
2013-02-20 12:31 ` Tang Chen [this message]
2013-02-20 12:31 ` Tang Chen
2013-02-20 12:35 ` Will Huck
2013-02-20 12:35 ` Will Huck
2013-02-20 22:41 ` Luck, Tony
2013-02-21 0:05 ` Will Huck
2013-02-21 0:23 ` Luck, Tony
2013-02-25 7:07 ` Will Huck
2013-02-25 9:01 ` Will Huck
2013-02-25 1:35 ` Will Huck
2013-02-25 3:32 ` Tang Chen
2013-02-25 19:06 ` Luck, Tony
2013-02-20 11:00 ` [Bug fix PATCH 2/2] acpi, movablemem_map: Make whatever nodes the kernel resides in un-hotpluggable Tang Chen
2013-02-20 11:00 ` Tang Chen
2013-02-23 19:26 ` Rob Landley
2013-02-23 19:26 ` Rob Landley
2013-02-25 2:54 ` Tang Chen
2013-02-25 2:54 ` Tang Chen
2013-02-20 21:36 ` [Bug fix PATCH 0/2] Make whatever node " Andrew Morton
2013-02-20 21:36 ` Andrew Morton
2013-02-21 3:03 ` Tang Chen
2013-02-21 3:03 ` Tang Chen
2013-02-21 7:03 ` Tang Chen
2013-02-21 7:03 ` Tang Chen
2013-02-23 19:40 ` Rob Landley
2013-02-23 19:40 ` Rob Landley
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=5124C22B.8030401@cn.fujitsu.com \
--to=tangchen@cn.fujitsu.com \
--cc=akpm@linux-foundation.org \
--cc=glommer@parallels.com \
--cc=guz.fnst@cn.fujitsu.com \
--cc=hpa@zytor.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=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.