All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tang Chen <tangchen@cn.fujitsu.com>
To: Rob Landley <rob@landley.net>
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: Mon, 25 Feb 2013 10:54:33 +0800	[thread overview]
Message-ID: <512AD269.2010900@cn.fujitsu.com> (raw)
In-Reply-To: <1361647596.11282.7@driftwood>

On 02/24/2013 03:26 AM, Rob Landley wrote:
> 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).

Hi Rob,

Thanks for ack. :)

>
>> @@ -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.

SFAIK, this is more useful when debugging.

>
>> 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?)

No, we cannot hot-plug/hot-unplug half a node. But we can offline some 
of the
memory, not all the memory on one node. :)

Here, hotplug means finally you will physically remove the hardware 
device from
the system while the system is running. So there is no such thing like 
hotplug
half a node, I think. :)

Thanks. :)

--
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: Rob Landley <rob@landley.net>
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: Mon, 25 Feb 2013 10:54:33 +0800	[thread overview]
Message-ID: <512AD269.2010900@cn.fujitsu.com> (raw)
In-Reply-To: <1361647596.11282.7@driftwood>

On 02/24/2013 03:26 AM, Rob Landley wrote:
> 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).

Hi Rob,

Thanks for ack. :)

>
>> @@ -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.

SFAIK, this is more useful when debugging.

>
>> 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?)

No, we cannot hot-plug/hot-unplug half a node. But we can offline some 
of the
memory, not all the memory on one node. :)

Here, hotplug means finally you will physically remove the hardware 
device from
the system while the system is running. So there is no such thing like 
hotplug
half a node, I think. :)

Thanks. :)

  reply	other threads:[~2013-02-25  2:55 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
2013-02-23 19:26     ` Rob Landley
2013-02-25  2:54     ` Tang Chen [this message]
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=512AD269.2010900@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.