From: Shaohui Zheng <shaohui.zheng@linux.intel.com>
To: David Rientjes <rientjes@google.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
haicheng.li@linux.intel.com, lethal@linux-sh.org,
Andi Kleen <ak@linux.intel.com>,
Greg Kroah-Hartman <gregkh@suse.de>
Subject: Re: [7/7,v8] NUMA Hotplug Emulator: Implement per-node add_memory debugfs interface
Date: Mon, 13 Dec 2010 10:09:25 +0800 [thread overview]
Message-ID: <20101213020924.GB19637@shaohui> (raw)
In-Reply-To: <alpine.DEB.2.00.1012101529190.30039@chino.kir.corp.google.com>
On Fri, Dec 10, 2010 at 03:30:38PM -0800, David Rientjes wrote:
> On Fri, 10 Dec 2010, Shaohui Zheng wrote:
>
> > > That doesn't address the question. My question is whether or not adding
> > > memory to a memoryless node in this way transitions its state to
> > > N_HIGH_MEMORY in the VM?
> > I guess that you are talking about memory hotplug on x86_32, memory hotplug is
> > NOT supported well for x86_32, and the function add_memory does not consider
> > this situlation.
> >
> > For 64bit, N_HIGH_MEMORY == N_NORMAL_MEMORY, so we need not to do the transition.
> >
>
> One more time :) Memoryless nodes do not have their bit set in
> N_HIGH_MEMORY. When memory is added to a memoryless node with this new
> interface, does the bit get set?
When we use debugfs add_node interface to add a fake node, the node was created,
and memory sections were created, but the state of the memory section is still
__offline__, so the new added node is still memoryless node. the result of debugfs
add_memory interface doing the similar thing with add_node, it just add memory
to an exists node.
For the state transition to N_HIGH_MEMORY, it does not happen on the above too
interfaces. It happens when the memory was onlined with sysfs /sys/device/system/memory/memoryXX/online
interface.
That is the code path:
store_mem_state
->memory_block_change_state
->memory_block_action
->online_pages
if (onlined_pages) {
kswapd_run(zone_to_nid(zone));
node_set_state(zone_to_nid(zone), N_HIGH_MEMORY);
}
does it address your question? thanks.
--
Thanks & Regards,
Shaohui
WARNING: multiple messages have this Message-ID (diff)
From: Shaohui Zheng <shaohui.zheng@linux.intel.com>
To: David Rientjes <rientjes@google.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
haicheng.li@linux.intel.com, lethal@linux-sh.org,
Andi Kleen <ak@linux.intel.com>,
Greg Kroah-Hartman <gregkh@suse.de>
Subject: Re: [7/7,v8] NUMA Hotplug Emulator: Implement per-node add_memory debugfs interface
Date: Mon, 13 Dec 2010 10:09:25 +0800 [thread overview]
Message-ID: <20101213020924.GB19637@shaohui> (raw)
In-Reply-To: <alpine.DEB.2.00.1012101529190.30039@chino.kir.corp.google.com>
On Fri, Dec 10, 2010 at 03:30:38PM -0800, David Rientjes wrote:
> On Fri, 10 Dec 2010, Shaohui Zheng wrote:
>
> > > That doesn't address the question. My question is whether or not adding
> > > memory to a memoryless node in this way transitions its state to
> > > N_HIGH_MEMORY in the VM?
> > I guess that you are talking about memory hotplug on x86_32, memory hotplug is
> > NOT supported well for x86_32, and the function add_memory does not consider
> > this situlation.
> >
> > For 64bit, N_HIGH_MEMORY == N_NORMAL_MEMORY, so we need not to do the transition.
> >
>
> One more time :) Memoryless nodes do not have their bit set in
> N_HIGH_MEMORY. When memory is added to a memoryless node with this new
> interface, does the bit get set?
When we use debugfs add_node interface to add a fake node, the node was created,
and memory sections were created, but the state of the memory section is still
__offline__, so the new added node is still memoryless node. the result of debugfs
add_memory interface doing the similar thing with add_node, it just add memory
to an exists node.
For the state transition to N_HIGH_MEMORY, it does not happen on the above too
interfaces. It happens when the memory was onlined with sysfs /sys/device/system/memory/memoryXX/online
interface.
That is the code path:
store_mem_state
->memory_block_change_state
->memory_block_action
->online_pages
if (onlined_pages) {
kswapd_run(zone_to_nid(zone));
node_set_state(zone_to_nid(zone), N_HIGH_MEMORY);
}
does it address your question? thanks.
--
Thanks & Regards,
Shaohui
--
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/ .
Fight unfair telecom policy in Canada: sign http://dissolvethecrtc.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2010-12-13 3:33 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <A24AE1FFE7AEC5489F83450EE98351BF2A40FED20A@shsmsx502.ccr.corp.intel.com>
2010-12-09 1:21 ` [7/7,v8] NUMA Hotplug Emulator: Implement per-node add_memory debugfs interface Shaohui Zheng
2010-12-09 1:21 ` Shaohui Zheng
2010-12-09 21:29 ` David Rientjes
2010-12-09 21:29 ` David Rientjes
2010-12-09 23:57 ` Shaohui Zheng
2010-12-09 23:57 ` Shaohui Zheng
2010-12-10 23:30 ` David Rientjes
2010-12-10 23:30 ` David Rientjes
2010-12-13 2:09 ` Shaohui Zheng [this message]
2010-12-13 2:09 ` Shaohui Zheng
2010-12-13 20:56 ` David Rientjes
2010-12-13 20:56 ` David Rientjes
2010-12-07 1:00 [0/7,v8] NUMA Hotplug Emulator (v8) shaohui.zheng
2010-12-07 1:00 ` [7/7,v8] NUMA Hotplug Emulator: Implement per-node add_memory debugfs interface shaohui.zheng
2010-12-07 1:00 ` shaohui.zheng
2010-12-08 21:31 ` David Rientjes
2010-12-08 21:31 ` David Rientjes
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=20101213020924.GB19637@shaohui \
--to=shaohui.zheng@linux.intel.com \
--cc=ak@linux.intel.com \
--cc=akpm@linux-foundation.org \
--cc=gregkh@suse.de \
--cc=haicheng.li@linux.intel.com \
--cc=lethal@linux-sh.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=rientjes@google.com \
/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.