From: "Zheng, Shaohui" <shaohui.zheng@intel.com>
To: David Rientjes <rientjes@google.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"lethal@linux-sh.org" <lethal@linux-sh.org>,
Andi Kleen <ak@linux.intel.com>,
Dave Hansen <dave@linux.vnet.ibm.com>, Greg KH <gregkh@suse.de>,
"Li, Haicheng" <haicheng.li@intel.com>,
"shaohui.zheng@linux.intel.com" <shaohui.zheng@linux.intel.com>
Subject: RE: [8/8, v6] NUMA Hotplug Emulator: implement debugfs interface for memory probe
Date: Mon, 6 Dec 2010 09:22:54 +0800 [thread overview]
Message-ID: <A24AE1FFE7AEC5489F83450EE98351BF28B3BB8C31@shsmsx502.ccr.corp.intel.com> (raw)
In-Reply-To: <alpine.DEB.2.00.1012021528170.6878@chino.kir.corp.google.com>
After introduce the per-node interface, the following directive can be avoided.
echo '0x80000000,3' > /sys/kernel/debug/mem_hotplug/add_memory
echo 'physical_addr=0x80000000 node_id=3' > /sys/kernel/debug/mem_hotplug/add_memory
I already implemented a draft in another thread, and waiting for comments, thanks for the proposal.
Thanks & Regards,
Shaohui
-----Original Message-----
From: David Rientjes [mailto:rientjes@google.com]
Sent: Friday, December 03, 2010 7:34 AM
To: Zheng, Shaohui
Cc: Andrew Morton; linux-mm@kvack.org; linux-kernel@vger.kernel.org; lethal@linux-sh.org; Andi Kleen; Dave Hansen; Greg KH; Li, Haicheng
Subject: RE: [8/8, v6] NUMA Hotplug Emulator: implement debugfs interface for memory probe
On Thu, 2 Dec 2010, Zheng, Shaohui wrote:
> Why should we add so many interfaces for memory hotplug emulation?
Because they are functionally different from real memory hotplug and we
want to support different configurations such as mapping memory to a
different node id or onlining physical nodes that don't exist.
They are in debugfs because the emulation, unlike real memory hotplug, is
used only for testing and debugging.
> If so, we should create both sysfs and debugfs
> entries for an online node, we are trying to add redundant code logic.
>
We do not need sysfs triggers for onlining a node, that already happens
automatically if the memory that is being onlined has a hotpluggable node
entry in the SRAT that has an offline node id.
> We need not make a simple thing such complicated, Simple is beautiful, I'd prefer to rename the mem_hotplug/probe
> interface as mem_hotplug/add_memory.
>
> /sys/kernel/debug/mem_hotplug/add_node (already exists)
> /sys/kernel/debug/mem_hotplug/add_memory (rename probe as add_memory)
>
No, add_memory would then require these bizarre lines that you've been
parsing like
echo 'physical_addr=0x80000000 node_id=3' > /sys/kernel/debug/mem_hotplug/add_memory
which is unnecessary if you introduce my proposal for per-node debugfs
directories similar to that under /sys/devices/system/node that is
extendable later if we add additional per-node triggers under
CONFIG_DEBUG_FS.
Adding /sys/kernel/debug/mem_hotplug/node2/add_memory that you write a
physical address to is a much more robust, simple, and extendable
interface.
--
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-06 1:23 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <A24AE1FFE7AEC5489F83450EE98351BF288D88D224@shsmsx502.ccr.corp.intel.com>
2010-12-02 0:27 ` Shaohui Zheng
2010-12-02 2:13 ` David Rientjes
2010-12-02 2:35 ` Zheng, Shaohui
2010-12-02 23:34 ` David Rientjes
2010-12-06 1:22 ` Zheng, Shaohui [this message]
2010-11-30 7:13 [0/8, v6] NUMA Hotplug Emulator(v6) - Introduction & Feedbacks shaohui.zheng
2010-11-30 7:13 ` [8/8, v6] NUMA Hotplug Emulator: implement debugfs interface for memory probe shaohui.zheng
2010-12-02 0:57 ` David Rientjes
2010-12-01 23:45 ` Shaohui Zheng
2010-12-02 1:21 ` 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=A24AE1FFE7AEC5489F83450EE98351BF28B3BB8C31@shsmsx502.ccr.corp.intel.com \
--to=shaohui.zheng@intel.com \
--cc=ak@linux.intel.com \
--cc=akpm@linux-foundation.org \
--cc=dave@linux.vnet.ibm.com \
--cc=gregkh@suse.de \
--cc=haicheng.li@intel.com \
--cc=lethal@linux-sh.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=rientjes@google.com \
--cc=shaohui.zheng@linux.intel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox