linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
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>

  reply	other threads:[~2013-02-20 12:32 UTC|newest]

Thread overview: 19+ 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 ` [Bug fix PATCH 1/2] acpi, movablemem_map: Exclude memblock.reserved ranges when parsing SRAT Tang Chen
2013-02-20 12:31   ` Tang Chen [this message]
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-23 19:26   ` Rob Landley
2013-02-25  2:54     ` Tang Chen
2013-02-20 21:36 ` [Bug fix PATCH 0/2] Make whatever node " Andrew Morton
2013-02-21  3:03   ` Tang Chen
2013-02-21  7:03   ` Tang Chen
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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox