All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rob Landley <rob@landley.net>
To: Tang Chen <tangchen@cn.fujitsu.com>
Cc: 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, 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: [Bug fix PATCH 2/2] acpi, movablemem_map: Make whatever nodes the kernel resides in un-hotpluggable.
Date: Sat, 23 Feb 2013 13:26:36 -0600	[thread overview]
Message-ID: <1361647596.11282.7@driftwood> (raw)
In-Reply-To: <1361358056-1793-3-git-send-email-tangchen@cn.fujitsu.com> (from tangchen@cn.fujitsu.com on Wed Feb 20 05:00:56 2013)

On 02/20/2013 05:00:56 AM, Tang Chen wrote:
> There could be several memory ranges in the node in which the kernel  
> resides.
> When using movablemem_map=acpi, we may skip one range that have  
> memory reserved
> by memblock. But if it is too small, then the kernel will fail to  
> boot. So, make
> the whole node which the kernel resides in un-hotpluggable. Then the  
> kernel has
> enough memory to use.
> 
> Reported-by: H Peter Anvin <hpa@zytor.com>
> Signed-off-by: Tang Chen <tangchen@cn.fujitsu.com>

Docs part Acked-by: Rob Landley <rob@landley.net> (with minor  
non-blocking snark).

> @@ -1673,6 +1675,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 the node  
> the
> +			      kernel resides in as hotpluggable so that  
> this
> +			      option can be used as a workaround of  
> firmware
> +                              bugs.

I usually see workaround "for", not "of". And your whitespace is  
inconsistent on that last line.

And I'm now kind of curious what such a workaround would accomplish,  
but I'm suspect it's obvious to people who wind up needing it.

>  	MTD_Partition=	[MTD]
>  			Format: <name>,<region-number>,<size>,<offset>
> diff --git a/arch/x86/mm/srat.c b/arch/x86/mm/srat.c
> index b8028b2..79836d0 100644
> --- a/arch/x86/mm/srat.c
> +++ b/arch/x86/mm/srat.c
> @@ -166,6 +166,9 @@ handle_movablemem(int node, u64 start, u64 end,  
> u32 hotpluggable)
>  	 * 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.
> +	 * Furthermore, to ensure the kernel has enough memory to boot,  
> we make
> +	 * all the memory on the node which the kernel resides in
> +	 * un-hotpluggable.
>  	 */

Can you hot-unplug half a node? (Do you have a choice with the  
granularity here?)

Rob
--
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: Rob Landley <rob@landley.net>
To: Tang Chen <tangchen@cn.fujitsu.com>
Cc: 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, 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: [Bug fix PATCH 2/2] acpi, movablemem_map: Make whatever nodes the kernel resides in un-hotpluggable.
Date: Sat, 23 Feb 2013 13:26:36 -0600	[thread overview]
Message-ID: <1361647596.11282.7@driftwood> (raw)
In-Reply-To: <1361358056-1793-3-git-send-email-tangchen@cn.fujitsu.com> (from tangchen@cn.fujitsu.com on Wed Feb 20 05:00:56 2013)

On 02/20/2013 05:00:56 AM, Tang Chen wrote:
> There could be several memory ranges in the node in which the kernel  
> resides.
> When using movablemem_map=acpi, we may skip one range that have  
> memory reserved
> by memblock. But if it is too small, then the kernel will fail to  
> boot. So, make
> the whole node which the kernel resides in un-hotpluggable. Then the  
> kernel has
> enough memory to use.
> 
> Reported-by: H Peter Anvin <hpa@zytor.com>
> Signed-off-by: Tang Chen <tangchen@cn.fujitsu.com>

Docs part Acked-by: Rob Landley <rob@landley.net> (with minor  
non-blocking snark).

> @@ -1673,6 +1675,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 the node  
> the
> +			      kernel resides in as hotpluggable so that  
> this
> +			      option can be used as a workaround of  
> firmware
> +                              bugs.

I usually see workaround "for", not "of". And your whitespace is  
inconsistent on that last line.

And I'm now kind of curious what such a workaround would accomplish,  
but I'm suspect it's obvious to people who wind up needing it.

>  	MTD_Partition=	[MTD]
>  			Format: <name>,<region-number>,<size>,<offset>
> diff --git a/arch/x86/mm/srat.c b/arch/x86/mm/srat.c
> index b8028b2..79836d0 100644
> --- a/arch/x86/mm/srat.c
> +++ b/arch/x86/mm/srat.c
> @@ -166,6 +166,9 @@ handle_movablemem(int node, u64 start, u64 end,  
> u32 hotpluggable)
>  	 * 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.
> +	 * Furthermore, to ensure the kernel has enough memory to boot,  
> we make
> +	 * all the memory on the node which the kernel resides in
> +	 * un-hotpluggable.
>  	 */

Can you hot-unplug half a node? (Do you have a choice with the  
granularity here?)

Rob

  reply	other threads:[~2013-02-23 21:33 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
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 [this message]
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=1361647596.11282.7@driftwood \
    --to=rob@landley.net \
    --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=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.