From: Haicheng Li <[email protected]>
NUMA hotplug emulator introduces a new node state N_HIDDEN to
identify the fake offlined node. It firstly hides RAM via E820
table and then emulates fake offlined nodes with the hidden RAM.
After system bootup, user is able to hotplug-add these offlined
nodes, which is just similar to a real hardware hotplug behavior.
Using boot option "numa=hide=N*size" to fake offlined nodes:
- N is the number of hidden nodes
- size is the memory size (in MB) per hidden node.
OPEN: Kernel might use part of hidden memory region as RAM buffer,
now emulator directly hide 128M extra space to workaround
this issue. Any better way to avoid this conflict?
CC: Yinghai Lu <[email protected]>
Signed-off-by: Haicheng Li <[email protected]>
Signed-off-by: Shaohui Zheng <[email protected]>
---
Index: linux-hpe4/arch/x86/include/asm/numa_64.h
===================================================================
--- linux-hpe4.orig/arch/x86/include/asm/numa_64.h 2010-11-15 17:13:02.453461462 +0800
+++ linux-hpe4/arch/x86/include/asm/numa_64.h 2010-11-15 17:13:07.093461818 +0800
@@ -37,7 +37,7 @@
extern void __cpuinit numa_add_cpu(int cpu);
extern void __cpuinit numa_remove_cpu(int cpu);
-#ifdef CONFIG_NUMA_EMU
+#if defined(CONFIG_NUMA_EMU) || defined(CONFIG_NODE_HOTPLUG_EMU)
#define FAKE_NODE_MIN_SIZE ((u64)64 << 20)
#define FAKE_NODE_MIN_HASH_MASK (~(FAKE_NODE_MIN_SIZE - 1UL))
#endif /* CONFIG_NUMA_EMU */
Index: linux-hpe4/arch/x86/mm/numa_64.c
===================================================================
--- linux-hpe4.orig/arch/x86/mm/numa_64.c 2010-11-15 17:13:02.463461371 +0800
+++ linux-hpe4/arch/x86/mm/numa_64.c 2010-11-15 17:21:05.510961676 +0800
@@ -304,6 +304,123 @@
}
}
+#ifdef CONFIG_NODE_HOTPLUG_EMU
+static char *hp_cmdline __initdata;
+static struct bootnode *hidden_nodes;
+static u64 hp_start;
+static long hidden_num, hp_size;
+static u64 nodes_size[MAX_NUMNODES] __initdata;
+
+int hotadd_hidden_nodes(int nid)
+{
+ int ret;
+
+ if (!node_hidden(nid))
+ return -EINVAL;
+
+ ret = add_memory(nid, hidden_nodes[nid].start,
+ hidden_nodes[nid].end - hidden_nodes[nid].start);
+ if (!ret) {
+ node_clear_hidden(nid);
+ return 0;
+ } else {
+ return -EEXIST;
+ }
+}
+
+/* parse the comand line for numa=hide */
+static long __init parse_hide_nodes(char *hp_cmdline)
+{
+ int coef = 1, nid = 0;
+ u64 size = 0;
+ long total = 0;
+ char buf[512], *p;
+
+ /* parse numa=hide command-line */
+ hidden_num = 0;
+ p = buf;
+ while (1) {
+ if (*hp_cmdline == ',' || *hp_cmdline == '\0') {
+ *p = '\0';
+ size = simple_strtoul(buf, NULL, 0);
+ printk(KERN_ERR "size: %dM buf:%s coef: %d.\n", (int)size, buf, coef);
+ if (!((size<<20) & FAKE_NODE_MIN_HASH_MASK))
+ printk(KERN_ERR "%d M is less than minimum node size, ignore it.\n", (int)size);
+
+ size <<= 20;
+ /* Round down to nearest FAKE_NODE_MIN_SIZE. */
+ size &= FAKE_NODE_MIN_HASH_MASK;
+
+ if (size) {
+ int i;
+ total += size * coef;
+ for (i = 0; i < coef; i++)
+ nodes_size[nid++] = size;
+ hidden_num += coef;
+ }
+
+ coef = 1;
+ p = buf;
+ if (*hp_cmdline == '\0')
+ break;
+ hp_cmdline++;
+ } else if (*hp_cmdline == '*') {
+ *p++ = '\0';
+ coef = simple_strtoul(buf, NULL, 0);
+ p = buf;
+ hp_cmdline++;
+ } else if (!isdigit(*hp_cmdline)) {
+ break;
+ }
+
+ *p++ = *hp_cmdline++;
+ }
+
+ return total;
+}
+
+static void __init numa_hide_nodes(void)
+{
+ hp_size = parse_hide_nodes(hp_cmdline);
+
+ hp_start = e820_hide_mem(hp_size);
+ if (hp_start <= 0) {
+ printk(KERN_ERR "Hide too much memory, disable node hotplug emualtion.");
+ hidden_num = 0;
+ return;
+ }
+
+ /* leave 128M space for possible RAM buffer usage later
+ any other better way to avoid this conflict?*/
+
+ e820_hide_mem(128*1024*1024);
+}
+
+static void __init numa_hotplug_emulation(void)
+{
+ int i, num_nodes = 0, nid;
+
+ for_each_online_node(i)
+ if (i > num_nodes)
+ num_nodes = i;
+
+ i = num_nodes + hidden_num;
+ if (!hidden_nodes) {
+ hidden_nodes = alloc_bootmem(sizeof(struct bootnode) * i);
+ memset(hidden_nodes, 0, sizeof(struct bootnode) * i);
+ }
+
+ nid = num_nodes + 1;
+ for (i = 0; i < hidden_num; i++) {
+ node_set(nid, node_possible_map);
+ hidden_nodes[nid].start = hp_start;
+ hidden_nodes[nid].end = hp_start + (nodes_size[i]);
+ hp_start = hidden_nodes[nid].end;
+ node_set_hidden(nid++);
+ }
+}
+#endif /* CONFIG_NODE_HOTPLUG_EMU */
+
#ifdef CONFIG_NUMA_EMU
/* Numa emulation */
static struct bootnode nodes[MAX_NUMNODES] __initdata;
@@ -658,7 +775,7 @@
#ifdef CONFIG_NUMA_EMU
if (cmdline && !numa_emulation(start_pfn, last_pfn, acpi, k8))
- return;
+ goto done;
nodes_clear(node_possible_map);
nodes_clear(node_online_map);
#endif
@@ -666,14 +783,14 @@
#ifdef CONFIG_ACPI_NUMA
if (!numa_off && acpi && !acpi_scan_nodes(start_pfn << PAGE_SHIFT,
last_pfn << PAGE_SHIFT))
- return;
+ goto done;
nodes_clear(node_possible_map);
nodes_clear(node_online_map);
#endif
#ifdef CONFIG_K8_NUMA
if (!numa_off && k8 && !k8_scan_nodes())
- return;
+ goto done;
nodes_clear(node_possible_map);
nodes_clear(node_online_map);
#endif
@@ -693,6 +810,13 @@
numa_set_node(i, 0);
e820_register_active_regions(0, start_pfn, last_pfn);
setup_node_bootmem(0, start_pfn << PAGE_SHIFT, last_pfn << PAGE_SHIFT);
+
+done:
+#ifdef CONFIG_NODE_HOTPLUG_EMU
+ if (hidden_num)
+ numa_hotplug_emulation();
+#endif
+ return;
}
unsigned long __init numa_free_all_bootmem(void)
@@ -720,6 +844,12 @@
if (!strncmp(opt, "fake=", 5))
cmdline = opt + 5;
#endif
+#ifdef CONFIG_NODE_HOTPLUG_EMU
+ if (!strncmp(opt, "hide=", 5)) {
+ hp_cmdline = opt + 5;
+ numa_hide_nodes();
+ }
+#endif
#ifdef CONFIG_ACPI_NUMA
if (!strncmp(opt, "noacpi", 6))
acpi_numa = -1;
Index: linux-hpe4/include/linux/nodemask.h
===================================================================
--- linux-hpe4.orig/include/linux/nodemask.h 2010-11-15 17:13:02.463461371 +0800
+++ linux-hpe4/include/linux/nodemask.h 2010-11-15 17:13:07.093461818 +0800
@@ -371,6 +371,10 @@
*/
enum node_states {
N_POSSIBLE, /* The node could become online at some point */
+#ifdef CONFIG_NODE_HOTPLUG_EMU
+ N_HIDDEN, /* The node is hidden at booting time, could be
+ * onlined in run time */
+#endif
N_ONLINE, /* The node is online */
N_NORMAL_MEMORY, /* The node has regular memory */
#ifdef CONFIG_HIGHMEM
@@ -470,6 +474,13 @@
#define node_online(node) node_state((node), N_ONLINE)
#define node_possible(node) node_state((node), N_POSSIBLE)
+#ifdef CONFIG_NODE_HOTPLUG_EMU
+#define node_set_hidden(node) node_set_state((node), N_HIDDEN)
+#define node_clear_hidden(node) node_clear_state((node), N_HIDDEN)
+#define node_hidden(node) node_state((node), N_HIDDEN)
+extern int hotadd_hidden_nodes(int nid);
+#endif
+
#define for_each_node(node) for_each_node_state(node, N_POSSIBLE)
#define for_each_online_node(node) for_each_node_state(node, N_ONLINE)
--
Thanks & Regards,
Shaohui
On Wed, 17 Nov 2010, [email protected] wrote:
> From: Haicheng Li <[email protected]>
>
> NUMA hotplug emulator introduces a new node state N_HIDDEN to
> identify the fake offlined node. It firstly hides RAM via E820
> table and then emulates fake offlined nodes with the hidden RAM.
>
Hmm, why can't you use numa=hide to hide a specified quantity of memory
from the kernel and then use the add_memory() interface to hot-add the
offlined memory in the desired quantity? In other words, why do you need
to track the offlined nodes with a state?
The userspace interface would take a desired size of hidden memory to
hot-add and the node id would be the first_unset_node(node_online_map).
> After system bootup, user is able to hotplug-add these offlined
> nodes, which is just similar to a real hardware hotplug behavior.
>
> Using boot option "numa=hide=N*size" to fake offlined nodes:
> - N is the number of hidden nodes
> - size is the memory size (in MB) per hidden node.
>
size should be parsed with memparse() so users can specify 'M' or 'G', it
would even make your parsing code simpler.
On Wed, Nov 17, 2010 at 12:16:47AM -0800, David Rientjes wrote:
> On Wed, 17 Nov 2010, [email protected] wrote:
>
> > From: Haicheng Li <[email protected]>
> >
> > NUMA hotplug emulator introduces a new node state N_HIDDEN to
> > identify the fake offlined node. It firstly hides RAM via E820
> > table and then emulates fake offlined nodes with the hidden RAM.
> >
>
> Hmm, why can't you use numa=hide to hide a specified quantity of memory
> from the kernel and then use the add_memory() interface to hot-add the
> offlined memory in the desired quantity? In other words, why do you need
> to track the offlined nodes with a state?
>
> The userspace interface would take a desired size of hidden memory to
> hot-add and the node id would be the first_unset_node(node_online_map).
Yes, it is a good idea, your solution is what we indeed do in our first 2
versions. We use mem=memsize to hide memory, and we call add_memory interface
to hot-add offlined memory with desired quantity, and we can also add to
desired nodes(even through the nodes does not exists). it is very flexible
solution.
However, this solution was denied since we notice NUMA emulation, we should
reuse it.
Currently, our solution creates static nodes when OS boots, only the node with
state N_HIDDEN can be hot-added with node/probe interface, and we can query
>
> > After system bootup, user is able to hotplug-add these offlined
> > nodes, which is just similar to a real hardware hotplug behavior.
> >
> > Using boot option "numa=hide=N*size" to fake offlined nodes:
> > - N is the number of hidden nodes
> > - size is the memory size (in MB) per hidden node.
> >
>
> size should be parsed with memparse() so users can specify 'M' or 'G', it
> would even make your parsing code simpler.
Agree, if we use memparse, users can specify 'M' or 'G', we will added it when
we send next version.
--
Thanks & Regards,
Shaohui
On Wed, 17 Nov 2010, Shaohui Zheng wrote:
> > Hmm, why can't you use numa=hide to hide a specified quantity of memory
> > from the kernel and then use the add_memory() interface to hot-add the
> > offlined memory in the desired quantity? In other words, why do you need
> > to track the offlined nodes with a state?
> >
> > The userspace interface would take a desired size of hidden memory to
> > hot-add and the node id would be the first_unset_node(node_online_map).
> Yes, it is a good idea, your solution is what we indeed do in our first 2
> versions. We use mem=memsize to hide memory, and we call add_memory interface
> to hot-add offlined memory with desired quantity, and we can also add to
> desired nodes(even through the nodes does not exists). it is very flexible
> solution.
>
> However, this solution was denied since we notice NUMA emulation, we should
> reuse it.
>
I don't understand why that's a requirement, NUMA emulation is a seperate
feature. Although both are primarily used to test and instrument other VM
and kernel code, NUMA emulation is restricted to only being used at boot
to fake nodes on smaller machines and can be used to test things like the
slab allocator. The NUMA hotplug emulator that you're developing here is
primarily used to test the hotplug callbacks; for that use-case, it seems
particularly helpful if nodes can be hotplugged of various sizes and node
ids rather than having static characteristics that cannot be changed with
a reboot.
> Currently, our solution creates static nodes when OS boots, only the node with
> state N_HIDDEN can be hot-added with node/probe interface, and we can query
>
The idea that I've proposed (and you've apparently thought about and even
implemented at one point) is much more powerful than that. We need not
query the state of hidden nodes that we've setup at boot but can rather
use the amount of hidden memory to setup the nodes in any way that we want
at runtime (various sizes, interleaved node ids, etc).
On Wed, Nov 17, 2010 at 01:10:50PM -0800, David Rientjes wrote:
> On Wed, 17 Nov 2010, Shaohui Zheng wrote:
>
> > > Hmm, why can't you use numa=hide to hide a specified quantity of memory
> > > from the kernel and then use the add_memory() interface to hot-add the
> > > offlined memory in the desired quantity? In other words, why do you need
> > > to track the offlined nodes with a state?
> > >
> > > The userspace interface would take a desired size of hidden memory to
> > > hot-add and the node id would be the first_unset_node(node_online_map).
> > Yes, it is a good idea, your solution is what we indeed do in our first 2
> > versions. We use mem=memsize to hide memory, and we call add_memory interface
> > to hot-add offlined memory with desired quantity, and we can also add to
> > desired nodes(even through the nodes does not exists). it is very flexible
> > solution.
> >
> > However, this solution was denied since we notice NUMA emulation, we should
> > reuse it.
> >
>
> I don't understand why that's a requirement, NUMA emulation is a seperate
> feature. Although both are primarily used to test and instrument other VM
> and kernel code, NUMA emulation is restricted to only being used at boot
> to fake nodes on smaller machines and can be used to test things like the
> slab allocator. The NUMA hotplug emulator that you're developing here is
> primarily used to test the hotplug callbacks; for that use-case, it seems
> particularly helpful if nodes can be hotplugged of various sizes and node
> ids rather than having static characteristics that cannot be changed with
> a reboot.
>
I agree with you. the early emulator do the same thing as you said, but there
is already NUMA emulation to create fake node, our emulator also creates
fake nodes. We worried about that we will suffer the critiques from the community,
so we drop the original degsin.
I did not know whether other engineers have the same attitude with you. I think
that I can publish both codes, and let the community to decide which one is prefered.
In my personal opinion, both methods are acceptable for me.
> > Currently, our solution creates static nodes when OS boots, only the node with
> > state N_HIDDEN can be hot-added with node/probe interface, and we can query
> >
>
> The idea that I've proposed (and you've apparently thought about and even
> implemented at one point) is much more powerful than that. We need not
> query the state of hidden nodes that we've setup at boot but can rather
> use the amount of hidden memory to setup the nodes in any way that we want
> at runtime (various sizes, interleaved node ids, etc).
yes, if we select your proposal. we just mark all the nodes as POSSIBLE node.
there is no hidden nodes any more. the node will be created after add memory
to the node first time.
This is the early patch( Not very formal, it is just an interanl version):
diff --git a/include/linux/nodemask.h b/include/linux/nodemask.h
index 454997c..9dc6a02 100644
--- a/include/linux/nodemask.h
+++ b/include/linux/nodemask.h
@@ -73,6 +73,7 @@
*
* node_set_online(node) set bit 'node' in node_online_map
* node_set_offline(node) clear bit 'node' in node_online_map
+ * node_set_possible(node) set bit 'node' in node_possible_map
*
* for_each_node(node) for-loop node over node_possible_map
* for_each_online_node(node) for-loop node over node_online_map
@@ -432,6 +433,11 @@ static inline void node_set_offline(int nid)
node_clear_state(nid, N_ONLINE);
nr_online_nodes = num_node_state(N_ONLINE);
}
+
+static inline void node_set_possible(int nid)
+{
+ node_set_state(nid, N_POSSIBLE);
+}
#else
static inline int node_state(int node, enum node_states state)
@@ -462,6 +468,7 @@ static inline int num_node_state(enum node_states state)
#define node_set_online(node) node_set_state((node), N_ONLINE)
#define node_set_offline(node) node_clear_state((node), N_ONLINE)
+#define node_set_possible(node) node_set_state((node), N_POSSIBLE)
#endif
#define node_online_map node_states[N_ONLINE]
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index eb40925..059ebf0 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -1602,6 +1602,9 @@ config HOTPLUG_CPU
( Note: power management support will enable this option
automatically on SMP systems. )
Say N if you want to disable CPU hotplug.
+config ARCH_CPU_PROBE_RELEASE
+ def_bool y
+ depends on HOTPLUG_CPU
config COMPAT_VDSO
def_bool y
diff --git a/arch/x86/mm/numa.c b/arch/x86/mm/numa.c
index 550df48..52094bc 100644
--- a/arch/x86/mm/numa.c
+++ b/arch/x86/mm/numa.c
@@ -26,12 +26,11 @@ void __init setup_node_to_cpumask_map(void)
{
unsigned int node, num = 0;
- /* setup nr_node_ids if not done yet */
- if (nr_node_ids == MAX_NUMNODES) {
- for_each_node_mask(node, node_possible_map)
- num = node;
- nr_node_ids = num + 1;
- }
+ /* re-setup nr_node_ids, when CONFIG_ARCH_MEMORY_PROBE enabled and mem=XXX
+ specified, nr_node_ids will be set as the maximum value */
+ for_each_node_mask(node, node_possible_map)
+ num = node;
+ nr_node_ids = num + 1;
/* allocate the map */
for (node = 0; node < nr_node_ids; node++)
diff --git a/drivers/base/memory.c b/drivers/base/memory.c
index bd02505..3d0e37c 100644
--- a/drivers/base/memory.c
+++ b/drivers/base/memory.c
@@ -327,6 +327,8 @@ static int block_size_init(void)
* will not need to do it from userspace. The fake hot-add code
* as well as ppc64 will do all of their discovery in userspace
* and will require this interface.
+ *
+ * Parameter format: start_addr, nid
*/
#ifdef CONFIG_ARCH_MEMORY_PROBE
static ssize_t
@@ -336,10 +338,26 @@ memory_probe_store(struct class *class, const char *buf, size_t count)
int nid;
int ret;
- phys_addr = simple_strtoull(buf, NULL, 0);
+ char *p = strchr(buf, ',');
+
+ if (p != NULL && strlen(p+1) > 0) {
+ /* nid specified */
+ *p++ = '\0';
+ nid = simple_strtoul(p, NULL, 0);
+ phys_addr = simple_strtoull(buf, NULL, 0);
+ } else {
+ phys_addr = simple_strtoull(buf, NULL, 0);
+ nid = memory_add_physaddr_to_nid(phys_addr);
+ }
- nid = memory_add_physaddr_to_nid(phys_addr);
- ret = add_memory(nid, phys_addr, PAGES_PER_SECTION << PAGE_SHIFT);
+ if (nid < 0 || nid > nr_node_ids - 1) {
+ printk(KERN_ERR "Invalid node id %d(0<=nid<%d).\n", nid, nr_node_ids);
+ } else {
+ printk(KERN_INFO "Add a memory section to node: %d.\n", nid);
+ ret = add_memory(nid, phys_addr, PAGES_PER_SECTION << PAGE_SHIFT);
+ if (ret)
+ count = ret;
+ }
if (ret)
count = ret;
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 8deb9d0..0d7eeea 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -3946,9 +3946,19 @@ static void __init setup_nr_node_ids(void)
unsigned int node;
unsigned int highest = 0;
+ #ifdef CONFIG_ARCH_MEMORY_PROBE
+ /* grub parameter mem=XXX specified */
+ if (1){
+ int cnt;
+ for (cnt = 0; cnt < MAX_NUMNODES; cnt++)
+ node_set_possible(cnt);
+ }
+ #endif
+
for_each_node_mask(node, node_possible_map)
highest = node;
nr_node_ids = highest + 1;
+ printk(KERN_INFO "setup_nr_node_ids: nr_node_ids : %d.\n", nr_node_ids);
}
#else
static inline void setup_nr_node_ids(void)
--
Thanks & Regards,
Shaohui
On Thu, Nov 18, 2010 at 12:14:07PM +0800, Shaohui Zheng wrote:
> On Wed, Nov 17, 2010 at 01:10:50PM -0800, David Rientjes wrote:
> > The idea that I've proposed (and you've apparently thought about and even
> > implemented at one point) is much more powerful than that. We need not
> > query the state of hidden nodes that we've setup at boot but can rather
> > use the amount of hidden memory to setup the nodes in any way that we want
> > at runtime (various sizes, interleaved node ids, etc).
>
> yes, if we select your proposal. we just mark all the nodes as POSSIBLE node.
> there is no hidden nodes any more. the node will be created after add memory
> to the node first time.
>
This is roughly what I had in mind in my N_HIDDEN review, so I quite
favour this approach.
On Thu, Nov 18, 2010 at 03:27:15PM +0900, Paul Mundt wrote:
> On Thu, Nov 18, 2010 at 12:14:07PM +0800, Shaohui Zheng wrote:
> > On Wed, Nov 17, 2010 at 01:10:50PM -0800, David Rientjes wrote:
> > > The idea that I've proposed (and you've apparently thought about and even
> > > implemented at one point) is much more powerful than that. We need not
> > > query the state of hidden nodes that we've setup at boot but can rather
> > > use the amount of hidden memory to setup the nodes in any way that we want
> > > at runtime (various sizes, interleaved node ids, etc).
> >
> > yes, if we select your proposal. we just mark all the nodes as POSSIBLE node.
> > there is no hidden nodes any more. the node will be created after add memory
> > to the node first time.
> >
> This is roughly what I had in mind in my N_HIDDEN review, so I quite
> favour this approach.
Our testing shows that it is a feasible approach, and it works well.
however, there is still a problem which we should worry about.
in our draft patch, we re-setup nr_node_ids when CONFIG_ARCH_MEMORY_PROBE enabled
and mem=XXX was specified in grub. we set nr_node_ids as MAX_NUMNODES + 1, because
we do not know how many nodes will be hot-added through memory/probe interface.
it might be a little wasting of memory.
--
Thanks & Regards,
Shaohui
On Thu, 18 Nov 2010, Shaohui Zheng wrote:
> On Wed, Nov 17, 2010 at 01:10:50PM -0800, David Rientjes wrote:
> > I don't understand why that's a requirement, NUMA emulation is a seperate
> > feature. Although both are primarily used to test and instrument other VM
> > and kernel code, NUMA emulation is restricted to only being used at boot
> > to fake nodes on smaller machines and can be used to test things like the
> > slab allocator. The NUMA hotplug emulator that you're developing here is
> > primarily used to test the hotplug callbacks; for that use-case, it seems
> > particularly helpful if nodes can be hotplugged of various sizes and node
> > ids rather than having static characteristics that cannot be changed with
> > a reboot.
> >
> I agree with you. the early emulator do the same thing as you said, but there
> is already NUMA emulation to create fake node, our emulator also creates
> fake nodes. We worried about that we will suffer the critiques from the community,
> so we drop the original degsin.
>
> I did not know whether other engineers have the same attitude with you. I think
> that I can publish both codes, and let the community to decide which one is prefered.
>
> In my personal opinion, both methods are acceptable for me.
>
The way that I've proposed it in my email to Dave was different: we use
the memory hotplug interface to add and online the memory only after an
interface has been added that will change the node mappings to
first_unset_node(node_online_map). The memory hotplug interface may
create a new pgdat, so this is the node creation mechanism that should be
used as opposed to those in NUMA emulation.
On Thu, 18 Nov 2010, Shaohui Zheng wrote:
> in our draft patch, we re-setup nr_node_ids when CONFIG_ARCH_MEMORY_PROBE enabled
> and mem=XXX was specified in grub. we set nr_node_ids as MAX_NUMNODES + 1, because
> we do not know how many nodes will be hot-added through memory/probe interface.
> it might be a little wasting of memory.
>
nr_node_ids need not be set to anything different at boot, the
MEM_GOING_ONLINE callback should be used for anything (like the slab
allocators) where a new node is introduced and needs to be dealt with
accordingly; this is how regular memory hotplug works, we need no
additional code in this regard because it's emulated. If a subsystem
needs to change in response to a new node going online and doesn't as a
result of using your emulator, that's a bug and either needs to be fixed
or prohibited from use with CONFIG_MEMORY_HOTPLUG.
(See the MEM_GOING_ONLINE callback in mm/slub.c, for instance, which deals
only with the case of node hotplug.)
On Thu, Nov 18, 2010 at 01:24:52PM -0800, David Rientjes wrote:
> On Thu, 18 Nov 2010, Shaohui Zheng wrote:
>
> > in our draft patch, we re-setup nr_node_ids when CONFIG_ARCH_MEMORY_PROBE enabled
> > and mem=XXX was specified in grub. we set nr_node_ids as MAX_NUMNODES + 1, because
> > we do not know how many nodes will be hot-added through memory/probe interface.
> > it might be a little wasting of memory.
> >
>
> nr_node_ids need not be set to anything different at boot, the
> MEM_GOING_ONLINE callback should be used for anything (like the slab
> allocators) where a new node is introduced and needs to be dealt with
> accordingly; this is how regular memory hotplug works, we need no
> additional code in this regard because it's emulated. If a subsystem
> needs to change in response to a new node going online and doesn't as a
> result of using your emulator, that's a bug and either needs to be fixed
> or prohibited from use with CONFIG_MEMORY_HOTPLUG.
>
> (See the MEM_GOING_ONLINE callback in mm/slub.c, for instance, which deals
> only with the case of node hotplug.)
nr_node_ids is the possible node number. when we do regular memory online,
it is oline to a possible node, and it is already counted in to nr_node_ids.
if you increment nr_node_ids dynamically when node online, it causes a lot of
problems. Many data are initialized according to nr_node_ids. That is our
experience when we debug the emulator.
mm/page_alloc.c:
/*
* Figure out the number of possible node ids.
*/
static void __init setup_nr_node_ids(void)
{
unsigned int node;
unsigned int highest = 0;
for_each_node_mask(node, node_possible_map)
highest = node;
nr_node_ids = highest + 1;
}
There is no conflict between emulator and CONFIG_MEMORY_HOTPLUG. A real node can be
onlined because we already set it as _possible_; if emulator is enabled, all the
nodes were marked as _possbile_ node, the real ndoe is also included in.
--
Thanks & Regards,
Shaohui
On Fri, 19 Nov 2010, Shaohui Zheng wrote:
> nr_node_ids is the possible node number. when we do regular memory online,
> it is oline to a possible node, and it is already counted in to nr_node_ids.
>
> if you increment nr_node_ids dynamically when node online, it causes a lot of
> problems. Many data are initialized according to nr_node_ids. That is our
> experience when we debug the emulator.
>
I think what we'll end up wanting to do is something like this, which adds
a numa=possible=<N> parameter for x86; this will add an additional N
possible nodes to node_possible_map that we can use to online later. It
also adds a new /sys/devices/system/memory/add_node file which takes a
typical "size@start" value to hot-add an emulated node. For example,
using "mem=2G numa=possible=1" on the command line and doing
echo 128M@0x80000000" > /sys/devices/system/memory/add_node would hot-add
a node of 128M.
Comments?
---
diff --git a/arch/x86/mm/numa_64.c b/arch/x86/mm/numa_64.c
--- a/arch/x86/mm/numa_64.c
+++ b/arch/x86/mm/numa_64.c
@@ -33,6 +33,7 @@ s16 apicid_to_node[MAX_LOCAL_APIC] __cpuinitdata = {
int numa_off __initdata;
static unsigned long __initdata nodemap_addr;
static unsigned long __initdata nodemap_size;
+static unsigned long __initdata numa_possible_nodes;
/*
* Map cpu index to node index
@@ -611,7 +612,7 @@ void __init initmem_init(unsigned long start_pfn, unsigned long last_pfn,
#ifdef CONFIG_NUMA_EMU
if (cmdline && !numa_emulation(start_pfn, last_pfn, acpi, k8))
- return;
+ goto out;
nodes_clear(node_possible_map);
nodes_clear(node_online_map);
#endif
@@ -619,14 +620,14 @@ void __init initmem_init(unsigned long start_pfn, unsigned long last_pfn,
#ifdef CONFIG_ACPI_NUMA
if (!numa_off && acpi && !acpi_scan_nodes(start_pfn << PAGE_SHIFT,
last_pfn << PAGE_SHIFT))
- return;
+ goto out;
nodes_clear(node_possible_map);
nodes_clear(node_online_map);
#endif
#ifdef CONFIG_K8_NUMA
if (!numa_off && k8 && !k8_scan_nodes())
- return;
+ goto out;
nodes_clear(node_possible_map);
nodes_clear(node_online_map);
#endif
@@ -646,6 +647,15 @@ void __init initmem_init(unsigned long start_pfn, unsigned long last_pfn,
numa_set_node(i, 0);
memblock_x86_register_active_regions(0, start_pfn, last_pfn);
setup_node_bootmem(0, start_pfn << PAGE_SHIFT, last_pfn << PAGE_SHIFT);
+out: __maybe_unused
+ for (i = 0; i < numa_possible_nodes; i++) {
+ int nid;
+
+ nid = first_unset_node(node_possible_map);
+ if (nid == MAX_NUMNODES)
+ break;
+ node_set(nid, node_possible_map);
+ }
}
unsigned long __init numa_free_all_bootmem(void)
@@ -675,6 +685,8 @@ static __init int numa_setup(char *opt)
if (!strncmp(opt, "noacpi", 6))
acpi_numa = -1;
#endif
+ if (!strncmp(opt, "possible=", 9))
+ numa_possible_nodes = simple_strtoul(opt + 9, NULL, 0);
return 0;
}
early_param("numa", numa_setup);
diff --git a/drivers/base/memory.c b/drivers/base/memory.c
--- a/drivers/base/memory.c
+++ b/drivers/base/memory.c
@@ -353,10 +353,44 @@ memory_probe_store(struct class *class, struct class_attribute *attr,
}
static CLASS_ATTR(probe, S_IWUSR, NULL, memory_probe_store);
+static ssize_t
+memory_add_node_store(struct class *class, struct class_attribute *attr,
+ const char *buf, size_t count)
+{
+ nodemask_t mask;
+ u64 start, size;
+ char *p;
+ int nid;
+ int ret;
+
+ size = memparse(buf, &p);
+ if (size < (PAGES_PER_SECTION << PAGE_SHIFT))
+ return -EINVAL;
+ if (*p != '@')
+ return -EINVAL;
+
+ start = simple_strtoull(p + 1, NULL, 0);
+
+ nodes_andnot(mask, node_possible_map, node_online_map);
+ nid = first_node(mask);
+ if (nid == MAX_NUMNODES)
+ return -EINVAL;
+
+ ret = add_memory(nid, start, size);
+ return ret ? ret : count;
+}
+static CLASS_ATTR(add_node, S_IWUSR, NULL, memory_add_node_store);
+
static int memory_probe_init(void)
{
- return sysfs_create_file(&memory_sysdev_class.kset.kobj,
+ int err;
+
+ err = sysfs_create_file(&memory_sysdev_class.kset.kobj,
&class_attr_probe.attr);
+ if (err)
+ return err;
+ return sysfs_create_file(&memory_sysdev_class.kset.kobj,
+ &class_attr_add_node.attr);
}
#else
static inline int memory_probe_init(void)
Add an interface to allow new nodes to be added when performing memory
hot-add. This provides a convenient interface to test memory hotplug
notifier callbacks and surrounding hotplug code when new nodes are
onlined without actually having a machine with such hotpluggable SRAT
entries.
This adds a new interface at /sys/devices/system/memory/add_node that
behaves in a similar way to the memory hot-add "probe" interface. Its
format is size@start, where "size" is the size of the new node to be
added and "start" is the physical address of the new memory.
The new node id is a currently offline, but possible, node. The bit must
be set in node_possible_map so that nr_node_ids is sized appropriately.
For emulation on x86, for example, it would be possible to set aside
memory for hotplugged nodes (say, anything above 2G) and to add an
additional three nodes as being possible on boot with
mem=2G numa=possible=3
and then creating a new 128M node at runtime:
# echo 128M@0x80000000 > /sys/devices/system/memory/add_node
On node 1 totalpages: 0
init_memory_mapping: 0000000080000000-0000000088000000
0080000000 - 0088000000 page 2M
Once the new node has been added, its memory can be onlined. If this
memory represents memory section 16, for example:
# echo online > /sys/devices/system/memory/memory16/state
Built 2 zonelists in Node order, mobility grouping on. Total pages: 514846
Policy zone: Normal
[ The memory section(s) mapped to a particular node are visible via
/sys/devices/system/node/node1, in this example. ]
The new node is now hotplugged and ready for testing.
Signed-off-by: David Rientjes <[email protected]>
---
Documentation/memory-hotplug.txt | 24 ++++++++++++++++++++++++
drivers/base/memory.c | 36 +++++++++++++++++++++++++++++++++++-
2 files changed, 59 insertions(+), 1 deletions(-)
diff --git a/Documentation/memory-hotplug.txt b/Documentation/memory-hotplug.txt
--- a/Documentation/memory-hotplug.txt
+++ b/Documentation/memory-hotplug.txt
@@ -18,6 +18,7 @@ be changed often.
4. Physical memory hot-add phase
4.1 Hardware(Firmware) Support
4.2 Notify memory hot-add event by hand
+ 4.3 Node hotplug emulation
5. Logical Memory hot-add phase
5.1. State of memory
5.2. How to online memory
@@ -215,6 +216,29 @@ current implementation). You'll have to online memory by yourself.
Please see "How to online memory" in this text.
+4.3 Node hotplug emulation
+------------
+It is possible to test node hotplug by assigning the newly added memory to a
+new node id when using a different interface with a similar behavior to
+"probe" described in section 4.2. If a node id is possible (there are bits
+in /sys/devices/system/memory/possible that are not online), then it may be
+used to emulate a newly added node as the result of memory hotplug by using
+the "add_node" interface.
+
+The add_node interface is located at
+/sys/devices/system/memory/add_node
+
+You can create a new node of a specified size starting at the physical
+address of new memory by
+
+% echo size@start_address_of_new_memory > /sys/devices/system/memory/add_node
+
+Where "size" can be represented in megabytes or gigabytes (for example,
+"128M" or "1G"). The minumum size is that of a memory section.
+
+Once the new node has been added, it is possible to online the memory by
+toggling the "state" of its memory section(s) as described in section 5.1.
+
------------------------------
5. Logical Memory hot-add phase
diff --git a/drivers/base/memory.c b/drivers/base/memory.c
--- a/drivers/base/memory.c
+++ b/drivers/base/memory.c
@@ -353,10 +353,44 @@ memory_probe_store(struct class *class, struct class_attribute *attr,
}
static CLASS_ATTR(probe, S_IWUSR, NULL, memory_probe_store);
+static ssize_t
+memory_add_node_store(struct class *class, struct class_attribute *attr,
+ const char *buf, size_t count)
+{
+ nodemask_t mask;
+ u64 start, size;
+ char *p;
+ int nid;
+ int ret;
+
+ size = memparse(buf, &p);
+ if (size < (PAGES_PER_SECTION << PAGE_SHIFT))
+ return -EINVAL;
+ if (*p != '@')
+ return -EINVAL;
+
+ start = simple_strtoull(p + 1, NULL, 0);
+
+ nodes_andnot(mask, node_possible_map, node_online_map);
+ nid = first_node(mask);
+ if (nid == MAX_NUMNODES)
+ return -EINVAL;
+
+ ret = add_memory(nid, start, size);
+ return ret ? ret : count;
+}
+static CLASS_ATTR(add_node, S_IWUSR, NULL, memory_add_node_store);
+
static int memory_probe_init(void)
{
- return sysfs_create_file(&memory_sysdev_class.kset.kobj,
+ int err;
+
+ err = sysfs_create_file(&memory_sysdev_class.kset.kobj,
&class_attr_probe.attr);
+ if (err)
+ return err;
+ return sysfs_create_file(&memory_sysdev_class.kset.kobj,
+ &class_attr_add_node.attr);
}
#else
static inline int memory_probe_init(void)
Adds a numa=possible=<N> command line option to set an additional N nodes
as being possible for memory hotplug. This set of possible nodes
controls nr_node_ids and the sizes of several dynamically allocated node
arrays.
This allows memory hotplug to create new nodes for newly added memory
rather than binding it to existing nodes.
The first use-case for this will be node hotplug emulation which will use
these possible nodes to create new nodes to test the memory hotplug
callbacks and surrounding memory hotplug code.
Signed-off-by: David Rientjes <[email protected]>
---
Documentation/x86/x86_64/boot-options.txt | 4 ++++
arch/x86/mm/numa_64.c | 18 +++++++++++++++---
2 files changed, 19 insertions(+), 3 deletions(-)
diff --git a/Documentation/x86/x86_64/boot-options.txt b/Documentation/x86/x86_64/boot-options.txt
--- a/Documentation/x86/x86_64/boot-options.txt
+++ b/Documentation/x86/x86_64/boot-options.txt
@@ -174,6 +174,10 @@ NUMA
If given as an integer, fills all system RAM with N fake nodes
interleaved over physical nodes.
+ numa=possible=<N>
+ Sets an additional N nodes as being possible for memory
+ hotplug.
+
ACPI
acpi=off Don't enable ACPI
diff --git a/arch/x86/mm/numa_64.c b/arch/x86/mm/numa_64.c
--- a/arch/x86/mm/numa_64.c
+++ b/arch/x86/mm/numa_64.c
@@ -33,6 +33,7 @@ s16 apicid_to_node[MAX_LOCAL_APIC] __cpuinitdata = {
int numa_off __initdata;
static unsigned long __initdata nodemap_addr;
static unsigned long __initdata nodemap_size;
+static unsigned long __initdata numa_possible_nodes;
/*
* Map cpu index to node index
@@ -611,7 +612,7 @@ void __init initmem_init(unsigned long start_pfn, unsigned long last_pfn,
#ifdef CONFIG_NUMA_EMU
if (cmdline && !numa_emulation(start_pfn, last_pfn, acpi, k8))
- return;
+ goto out;
nodes_clear(node_possible_map);
nodes_clear(node_online_map);
#endif
@@ -619,14 +620,14 @@ void __init initmem_init(unsigned long start_pfn, unsigned long last_pfn,
#ifdef CONFIG_ACPI_NUMA
if (!numa_off && acpi && !acpi_scan_nodes(start_pfn << PAGE_SHIFT,
last_pfn << PAGE_SHIFT))
- return;
+ goto out;
nodes_clear(node_possible_map);
nodes_clear(node_online_map);
#endif
#ifdef CONFIG_K8_NUMA
if (!numa_off && k8 && !k8_scan_nodes())
- return;
+ goto out;
nodes_clear(node_possible_map);
nodes_clear(node_online_map);
#endif
@@ -646,6 +647,15 @@ void __init initmem_init(unsigned long start_pfn, unsigned long last_pfn,
numa_set_node(i, 0);
memblock_x86_register_active_regions(0, start_pfn, last_pfn);
setup_node_bootmem(0, start_pfn << PAGE_SHIFT, last_pfn << PAGE_SHIFT);
+out: __maybe_unused
+ for (i = 0; i < numa_possible_nodes; i++) {
+ int nid;
+
+ nid = first_unset_node(node_possible_map);
+ if (nid == MAX_NUMNODES)
+ break;
+ node_set(nid, node_possible_map);
+ }
}
unsigned long __init numa_free_all_bootmem(void)
@@ -675,6 +685,8 @@ static __init int numa_setup(char *opt)
if (!strncmp(opt, "noacpi", 6))
acpi_numa = -1;
#endif
+ if (!strncmp(opt, "possible=", 9))
+ numa_possible_nodes = simple_strtoul(opt + 9, NULL, 0);
return 0;
}
early_param("numa", numa_setup);
Hi, David
On Sat, Nov 20, 2010 at 06:28:31PM -0800, David Rientjes wrote:
>Adds a numa=possible=<N> command line option to set an additional N nodes
>as being possible for memory hotplug. This set of possible nodes
>controls nr_node_ids and the sizes of several dynamically allocated node
>arrays.
>
>This allows memory hotplug to create new nodes for newly added memory
>rather than binding it to existing nodes.
>
>The first use-case for this will be node hotplug emulation which will use
>these possible nodes to create new nodes to test the memory hotplug
>callbacks and surrounding memory hotplug code.
>
I am not sure how much value of making this dynamic,
for CPU, we do this at compile time, i.e. NR_CPUS,
so how about NR_NODES?
Also, numa=possible= is not as clear as numa=max=, for me at least.
Thanks.
David Rientjes wrote:
> On Fri, 19 Nov 2010, Shaohui Zheng wrote:
>
>> nr_node_ids is the possible node number. when we do regular memory
>> online, it is oline to a possible node, and it is already counted in
>> to nr_node_ids.
>>
>> if you increment nr_node_ids dynamically when node online, it causes
>> a lot of problems. Many data are initialized according to
>> nr_node_ids. That is our experience when we debug the emulator.
>>
>
> I think what we'll end up wanting to do is something like this, which
> adds
> a numa=possible=<N> parameter for x86; this will add an additional N
> possible nodes to node_possible_map that we can use to online later.
> It
> also adds a new /sys/devices/system/memory/add_node file which takes a
> typical "size@start" value to hot-add an emulated node. For example,
> using "mem=2G numa=possible=1" on the command line and doing
> echo 128M@0x80000000" > /sys/devices/system/memory/add_node would
> hot-add
> a node of 128M.
>
> Comments?
Sorry for the late response as I'm in a biz trip recently.
David, your original concern is just about powerful/flexibility. I'm sure our implementation can better meets such requirments.
IMHO, I don't see any powerful/flexibility from your patch, compared to our original implementation. you just make things more complex and mess.
Why not use "numa=hide=N*size" as originally implemented?
- later you just need to online the node once you want. And it naturally/exactly emulates the behavior that current HW provides.
- N is the possible node number. And we can use 128M as the default size for each hidden node if user doesn't specify a size.
- If user wants more mem for hidden node, he just needs specify the "size".
- besides, user can also use "mem=" to hide more mem and later use mem-add i/f to freely attach more mem to the hidden node during runtime.
Your patch introduces additional dependency on "mem=", but ours is simple and flexibly compatible with "mem=" and "numa=emu".
-haicheng-
On Sat, Nov 20, 2010 at 06:28:38PM -0800, David Rientjes wrote:
>
> Add an interface to allow new nodes to be added when performing memory
> hot-add. This provides a convenient interface to test memory hotplug
> notifier callbacks and surrounding hotplug code when new nodes are
> onlined without actually having a machine with such hotpluggable SRAT
> entries.
>
> This adds a new interface at /sys/devices/system/memory/add_node that
> behaves in a similar way to the memory hot-add "probe" interface. Its
> format is size@start, where "size" is the size of the new node to be
> added and "start" is the physical address of the new memory.
Ick, we are trying to clean up the system devices right now which would
prevent this type of tree being added.
> The new node id is a currently offline, but possible, node. The bit must
> be set in node_possible_map so that nr_node_ids is sized appropriately.
>
> For emulation on x86, for example, it would be possible to set aside
> memory for hotplugged nodes (say, anything above 2G) and to add an
> additional three nodes as being possible on boot with
>
> mem=2G numa=possible=3
>
> and then creating a new 128M node at runtime:
>
> # echo 128M@0x80000000 > /sys/devices/system/memory/add_node
> On node 1 totalpages: 0
> init_memory_mapping: 0000000080000000-0000000088000000
> 0080000000 - 0088000000 page 2M
>
> Once the new node has been added, its memory can be onlined. If this
> memory represents memory section 16, for example:
>
> # echo online > /sys/devices/system/memory/memory16/state
> Built 2 zonelists in Node order, mobility grouping on. Total pages: 514846
> Policy zone: Normal
>
> [ The memory section(s) mapped to a particular node are visible via
> /sys/devices/system/node/node1, in this example. ]
>
> The new node is now hotplugged and ready for testing.
>
> Signed-off-by: David Rientjes <[email protected]>
> ---
> Documentation/memory-hotplug.txt | 24 ++++++++++++++++++++++++
> drivers/base/memory.c | 36 +++++++++++++++++++++++++++++++++++-
> 2 files changed, 59 insertions(+), 1 deletions(-)
When adding sysfs files you need to document it in Documentation/ABI
instead.
But as this is a debugging thing, why not just put it in debugfs
instead?
thanks,
greg k-h
On Sun, 21 Nov 2010, Li, Haicheng wrote:
> > I think what we'll end up wanting to do is something like this, which
> > adds
> > a numa=possible=<N> parameter for x86; this will add an additional N
> > possible nodes to node_possible_map that we can use to online later.
> > It
> > also adds a new /sys/devices/system/memory/add_node file which takes a
> > typical "size@start" value to hot-add an emulated node. For example,
> > using "mem=2G numa=possible=1" on the command line and doing
> > echo 128M@0x80000000" > /sys/devices/system/memory/add_node would
> > hot-add
> > a node of 128M.
> >
> > Comments?
>
> Sorry for the late response as I'm in a biz trip recently.
>
> David, your original concern is just about powerful/flexibility. I'm
> sure our implementation can better meets such requirments.
>
Not with hacky hidden nodes or being unnecessarily tied to e820, it can't.
> IMHO, I don't see any powerful/flexibility from your patch, compared to
> our original implementation. you just make things more complex and mess.
> Why not use "numa=hide=N*size" as originally implemented?
Hidden nodes are a hack and completely unnecessary for node hotplug
emulation, there's no need to have additional nodemasks or node states
throughout the kernel. They also require that you define the node sizes
at boot, mine allows you to hotplug multiple node sizes of your choice at
runtime.
> - later you just need to online the node once you want. And it
> naturally/exactly emulates the behavior that current HW provides.
My proposal allows you to hotplug various node sizes, they can be
offlined, their sizes can be subsequently changed, and re-hotplugged.
It's a very dynamic and flexible model that allows you to emulate all
possible combinations of node hotplug without constantly rebooting.
> - N is the possible node number. And we can use 128M as the default
> size for each hidden node if user doesn't specify a size.
My model allows you to define the node size you'd like to add at runtime.
> - If user wants more mem for hidden node, he just needs specify the
> "size".
> - besides, user can also use "mem=" to hide more mem and later use
> mem-add i/f to freely attach more mem to the hidden node during runtime.
>
Each of these requires a reboot, you cannot emulate hotplugging a node,
offlining it, removing the memory, and re-hotplugging the same node with a
larger amount of added memory with your model.
> Your patch introduces additional dependency on "mem=", but ours is
> simple and flexibly compatible with "mem=" and "numa=emu".
>
This is the natural use case of mem=, to truncate the memory map to only
allow the kernel to have a portion of usable memory. The remainder can be
used by this new interface, if desired, with complete power and control
over the size of nodes you're adding without having to conform to hidden
node sizes that you've specified at boot.
On Sun, 21 Nov 2010, Américo Wang wrote:
> I am not sure how much value of making this dynamic,
> for CPU, we do this at compile time, i.e. NR_CPUS,
> so how about NR_NODES?
>
This is outside the scope of node hotplug emulation, it needs to be built
on top of whatever the kernel implements.
> Also, numa=possible= is not as clear as numa=max=, for me at least.
>
I like name, but it requires that you know how many nodes that system
already has. In other words, numa=possible=4 allows you to specify that 4
additional nodes will be possible, but initially offline, for this or
other purposes. numa=max=4 would be no-op if the system actually had 4
nodes.
I chose numa=possible over numa=additional because it is more clearly tied
to node_possible_map, which is the only thing it modifies.
On Sun, 21 Nov 2010, Greg KH wrote:
> But as this is a debugging thing, why not just put it in debugfs
> instead?
>
Ok, I think Paul had a similar suggestion during the discussion of
Shaohui's patchset. I'll move it, thanks.
Add an interface to allow new nodes to be added when performing memory
hot-add. This provides a convenient interface to test memory hotplug
notifier callbacks and surrounding hotplug code when new nodes are
onlined without actually having a machine with such hotpluggable SRAT
entries.
This adds a new debugfs interface at /sys/kernel/debug/hotplug/add_node
that behaves in a similar way to the memory hot-add "probe" interface.
Its format is size@start, where "size" is the size of the new node to be
added and "start" is the physical address of the new memory.
The new node id is a currently offline, but possible, node. The bit must
be set in node_possible_map so that nr_node_ids is sized appropriately.
For emulation on x86, for example, it would be possible to set aside
memory for hotplugged nodes (say, anything above 2G) and to add an
additional four nodes as being possible on boot with
mem=2G numa=possible=4
and then creating a new 128M node at runtime:
# echo 128M@0x80000000 > /sys/kernel/debug/hotplug/add_node
On node 1 totalpages: 0
init_memory_mapping: 0000000080000000-0000000088000000
0080000000 - 0088000000 page 2M
Once the new node has been added, its memory can be onlined. If this
memory represents memory section 16, for example:
# echo online > /sys/devices/system/memory/memory16/state
Built 2 zonelists in Node order, mobility grouping on. Total pages: 514846
Policy zone: Normal
[ The memory section(s) mapped to a particular node are visible via
/sys/devices/system/node/node1, in this example. ]
The new node is now hotplugged and ready for testing.
Signed-off-by: David Rientjes <[email protected]>
---
v2: moved to debugfs as suggested by Greg KH
(patch 1/2: "x86: add numa=possible command line option" is still valid)
Documentation/memory-hotplug.txt | 24 +++++++++++++++
mm/memory_hotplug.c | 59 ++++++++++++++++++++++++++++++++++++++
2 files changed, 83 insertions(+), 0 deletions(-)
diff --git a/Documentation/memory-hotplug.txt b/Documentation/memory-hotplug.txt
--- a/Documentation/memory-hotplug.txt
+++ b/Documentation/memory-hotplug.txt
@@ -18,6 +18,7 @@ be changed often.
4. Physical memory hot-add phase
4.1 Hardware(Firmware) Support
4.2 Notify memory hot-add event by hand
+ 4.3 Node hotplug emulation
5. Logical Memory hot-add phase
5.1. State of memory
5.2. How to online memory
@@ -215,6 +216,29 @@ current implementation). You'll have to online memory by yourself.
Please see "How to online memory" in this text.
+4.3 Node hotplug emulation
+------------
+With debugfs, it is possible to test node hotplug by assigning the newly
+added memory to a new node id when using a different interface with a similar
+behavior to "probe" described in section 4.2. If a node id is possible
+(there are bits in /sys/devices/system/memory/possible that are not online),
+then it may be used to emulate a newly added node as the result of memory
+hotplug by using the debugfs "add_node" interface.
+
+The add_node interface is located at "hotplug/add_node" at the debugfs mount
+point.
+
+You can create a new node of a specified size starting at the physical
+address of new memory by
+
+% echo size@start_address_of_new_memory > /sys/kernel/debug/hotplug/add_node
+
+Where "size" can be represented in megabytes or gigabytes (for example,
+"128M" or "1G"). The minumum size is that of a memory section.
+
+Once the new node has been added, it is possible to online the memory by
+toggling the "state" of its memory section(s) as described in section 5.1.
+
------------------------------
5. Logical Memory hot-add phase
diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
--- a/mm/memory_hotplug.c
+++ b/mm/memory_hotplug.c
@@ -910,3 +910,62 @@ int remove_memory(u64 start, u64 size)
}
#endif /* CONFIG_MEMORY_HOTREMOVE */
EXPORT_SYMBOL_GPL(remove_memory);
+
+#ifdef CONFIG_DEBUG_FS
+#include <linux/debugfs.h>
+
+static struct dentry *hotplug_debug_root;
+
+static ssize_t add_node_store(struct file *file, const char __user *buf,
+ size_t count, loff_t *ppos)
+{
+ nodemask_t mask;
+ u64 start, size;
+ char buffer[64];
+ char *p;
+ int nid;
+ int ret;
+
+ memset(buffer, 0, sizeof(buffer));
+ if (count > sizeof(buffer) - 1)
+ count = sizeof(buffer) - 1;
+ if (copy_from_user(buffer, buf, count))
+ return -EFAULT;
+
+ size = memparse(buffer, &p);
+ if (size < (PAGES_PER_SECTION << PAGE_SHIFT))
+ return -EINVAL;
+ if (*p != '@')
+ return -EINVAL;
+
+ start = simple_strtoull(p + 1, NULL, 0);
+
+ nodes_andnot(mask, node_possible_map, node_online_map);
+ nid = first_node(mask);
+ if (nid == MAX_NUMNODES)
+ return -ENOMEM;
+
+ ret = add_memory(nid, start, size);
+ return ret ? ret : count;
+}
+
+static const struct file_operations add_node_file_ops = {
+ .write = add_node_store,
+ .llseek = generic_file_llseek,
+};
+
+static int __init hotplug_debug_init(void)
+{
+ hotplug_debug_root = debugfs_create_dir("hotplug", NULL);
+ if (!hotplug_debug_root)
+ return -ENOMEM;
+
+ if (!debugfs_create_file("add_node", S_IWUSR, hotplug_debug_root,
+ NULL, &add_node_file_ops))
+ return -ENOMEM;
+
+ return 0;
+}
+
+module_init(hotplug_debug_init);
+#endif /* CONFIG_DEBUG_FS */
On Sun, Nov 21, 2010 at 03:08:17PM -0800, David Rientjes wrote:
> Add an interface to allow new nodes to be added when performing memory
> hot-add. This provides a convenient interface to test memory hotplug
> notifier callbacks and surrounding hotplug code when new nodes are
> onlined without actually having a machine with such hotpluggable SRAT
> entries.
>
> This adds a new debugfs interface at /sys/kernel/debug/hotplug/add_node
The rule for debugfs is "there are no rules", but perhaps you might want
to name "hotplug" a bit more specific for what you are doing? "hotplug"
means pretty much anything these days, so how about s/hotplug/node/
instead as that is what you are controlling.
Just a suggestion...
greg k-h
On Mon, Nov 22, 2010 at 09:47:02AM +0800, Zheng, Shaohui wrote:
> Add an interface to allow new nodes to be added when performing memory
> hot-add. This provides a convenient interface to test memory hotplug
> notifier callbacks and surrounding hotplug code when new nodes are
> onlined without actually having a machine with such hotpluggable SRAT
> entries.
>
> This adds a new interface at /sys/devices/system/memory/add_node that
> behaves in a similar way to the memory hot-add "probe" interface. Its
> format is size@start, where "size" is the size of the new node to be
> added and "start" is the physical address of the new memory.
>
> The new node id is a currently offline, but possible, node. The bit must
> be set in node_possible_map so that nr_node_ids is sized appropriately.
>
> For emulation on x86, for example, it would be possible to set aside
> memory for hotplugged nodes (say, anything above 2G) and to add an
> additional three nodes as being possible on boot with
>
> mem=2G numa=possible=3
>
> and then creating a new 128M node at runtime:
>
> # echo 128M@0x80000000 > /sys/devices/system/memory/add_node
> On node 1 totalpages: 0
> init_memory_mapping: 0000000080000000-0000000088000000
> 0080000000 - 0088000000 page 2M
For cpu/memory physical hotplug, we have the unique interface probe/release,
it is the _standard_ interface, it is not only for x86, ppc use the the interface
as well. For node hotplug, it should follow the rule.
You are creating a new interface /sys/devices/system/memory/add_node to add both
memory and node, you are just trying to create DUPLICATED feature with the
memory probe interface, it breaks the rule.
I did NOT see the feature difference with our emulator patch http://lkml.org/lkml/2010/11/16/740,
you pick up a piece of feature from emulator, and create an other thread. You
are trying to replace the interface with a new one, which is not recommended.
the memory probe interface is already powerful and flexible enough after apply
our patch. What's more important, it keeps the old directives, and it maintains
backwards compatibility.
Add a memory section(128M) to node 3(boots with mem=1024m)
echo 0x40000000,3 > memory/probe
And more we make it friendly, it is possible to add memory to do
echo 3g > memory/probe
echo 1024m,3 > memory/probe
It maintains backwards compatibility.
Another format suggested by Dave Hansen:
echo physical_address=0x40000000 numa_node=3 > memory/probe
we should not need duplicated interface /sys/devices/system/memory/add_node here.
> Adds a numa=possible=<N> command line option to set an additional N nodes
> as being possible for memory hotplug. This set of possible nodes
> controls nr_node_ids and the sizes of several dynamically allocated node
> arrays.
>
> This allows memory hotplug to create new nodes for newly added memory
> rather than binding it to existing nodes.
>
> The first use-case for this will be node hotplug emulation which will use
> these possible nodes to create new nodes to test the memory hotplug
> callbacks and surrounding memory hotplug code.
It is the improved solution from thread http://lkml.org/lkml/2010/11/18/3,
our draft patch set all the nodes as possbile node, it wastes a lot of memory,
the command line numa=possible=<N> seems to be an acceptable, and it is a optimization
for our patch.
I like your active work attitude for the patch reviewing, it is real helpful to
improve the patch quality.
the NUMA Hotplug Emulator is an overall solution for Node/CPU/Memory hotplug
emulation, it includes a lot of engineers' review comments and feedbacks in the
mailling list. We review and test each version very carefully, and make sure
each version is very stable and it includes in most of the feedbacks, so we deliver
each version very slow.
we do NOT want to split the emulator into many parts, and want to maintain them together.
How about add this patch into our emulator patchset, and add your sign-off?. Thanks.
On Sun, Nov 21, 2010 at 01:46:07PM -0800, David Rientjes wrote:
>On Sun, 21 Nov 2010, Américo Wang wrote:
>> Also, numa=possible= is not as clear as numa=max=, for me at least.
>>
>
>I like name, but it requires that you know how many nodes that system
>already has. In other words, numa=possible=4 allows you to specify that 4
>additional nodes will be possible, but initially offline, for this or
>other purposes. numa=max=4 would be no-op if the system actually had 4
>nodes.
>
>I chose numa=possible over numa=additional because it is more clearly tied
>to node_possible_map, which is the only thing it modifies.
Okay, I thought "possible" means "max", but "possible" means "addtional" here.
It's clear for me now.
Thanks!
On Mon, Nov 22, 2010 at 09:47:06AM +0800, Shaohui Zheng wrote:
> On Mon, Nov 22, 2010 at 09:47:02AM +0800, Zheng, Shaohui wrote:
>
> For cpu/memory physical hotplug, we have the unique interface probe/release,
> it is the _standard_ interface, it is not only for x86, ppc use the the interface
> as well. For node hotplug, it should follow the rule.
>
> You are creating a new interface /sys/devices/system/memory/add_node to add both
> memory and node, you are just trying to create DUPLICATED feature with the
> memory probe interface, it breaks the rule.
>
> I did NOT see the feature difference with our emulator patch http://lkml.org/lkml/2010/11/16/740,
> you pick up a piece of feature from emulator, and create an other thread. You
> are trying to replace the interface with a new one, which is not recommended.
> the memory probe interface is already powerful and flexible enough after apply
> our patch. What's more important, it keeps the old directives, and it maintains
> backwards compatibility.
>
> Add a memory section(128M) to node 3(boots with mem=1024m)
>
> echo 0x40000000,3 > memory/probe
>
> And more we make it friendly, it is possible to add memory to do
>
> echo 3g > memory/probe
> echo 1024m,3 > memory/probe
>
> It maintains backwards compatibility.
>
> Another format suggested by Dave Hansen:
>
> echo physical_address=0x40000000 numa_node=3 > memory/probe
>
> we should not need duplicated interface /sys/devices/system/memory/add_node here.
ah, a long time silence.
Does somebody know the status of this patch, is it accepted by the maintainer?
I am not in patch's CC list, so I will not get mail notice when the patch was
accepted by the maintainer.
the other hotplug emulator patches has dependency on this patch, so I can not
re-make my patchset if this patch is still pending. thanks.
--
Thanks & Regards,
Shaohui
On Sun, 21 Nov 2010, Greg KH wrote:
> > Add an interface to allow new nodes to be added when performing memory
> > hot-add. This provides a convenient interface to test memory hotplug
> > notifier callbacks and surrounding hotplug code when new nodes are
> > onlined without actually having a machine with such hotpluggable SRAT
> > entries.
> >
> > This adds a new debugfs interface at /sys/kernel/debug/hotplug/add_node
>
> The rule for debugfs is "there are no rules", but perhaps you might want
> to name "hotplug" a bit more specific for what you are doing? "hotplug"
> means pretty much anything these days, so how about s/hotplug/node/
> instead as that is what you are controlling.
>
> Just a suggestion...
>
Hmm, how strongly do you feel about that? There's nothing node specific
in the memory hotplug code where this lives, so we'd probably have to
define the dentry elsewhere and even then it would only needed for
CONFIG_MEMORY_HOTPLUG.
I personally don't see this as a node debugging but rather memory hotplug
callback debugging.
On Mon, 22 Nov 2010, Shaohui Zheng wrote:
> > and then creating a new 128M node at runtime:
> >
> > # echo 128M@0x80000000 > /sys/devices/system/memory/add_node
> > On node 1 totalpages: 0
> > init_memory_mapping: 0000000080000000-0000000088000000
> > 0080000000 - 0088000000 page 2M
>
> For cpu/memory physical hotplug, we have the unique interface probe/release,
> it is the _standard_ interface, it is not only for x86, ppc use the the interface
> as well. For node hotplug, it should follow the rule.
>
> You are creating a new interface /sys/devices/system/memory/add_node to add both
> memory and node, you are just trying to create DUPLICATED feature with the
> memory probe interface, it breaks the rule.
>
It's not duplicated, the function of add_node is distinct since it maps
the added memory to a node that wasn't previously defined (for the x86
case, defined by the SRAT). I think this is better than an additional
abstraction layer that remaps memory to nodes above what the BIOS has
defined, and there's nothing architecture specific about add_node; if an
arch can do probe then it can use this new interface.
> I did NOT see the feature difference with our emulator patch http://lkml.org/lkml/2010/11/16/740,
> you pick up a piece of feature from emulator, and create an other thread. You
> are trying to replace the interface with a new one, which is not recommended.
> the memory probe interface is already powerful and flexible enough after apply
> our patch. What's more important, it keeps the old directives, and it maintains
> backwards compatibility.
>
This achieves the same goal in a much cleaner and generic way. It doesn't
replace anything that currently sits in the kernel, instead it competes
directly with your model for node hotplug emulation.
> Add a memory section(128M) to node 3(boots with mem=1024m)
>
> echo 0x40000000,3 > memory/probe
>
> And more we make it friendly, it is possible to add memory to do
>
> echo 3g > memory/probe
> echo 1024m,3 > memory/probe
>
> It maintains backwards compatibility.
>
My patch doesn't break backwards compatibility, it adds a new debugfs file
that allows you to test node hotplug.
> Another format suggested by Dave Hansen:
>
> echo physical_address=0x40000000 numa_node=3 > memory/probe
>
> we should not need duplicated interface /sys/devices/system/memory/add_node here.
>
We don't need to define a node id, we only need to ensure that a possible
node is not yet online and use it; we don't gain anything by trying to
hotplug node ids in a sparse or interleaved way (although it is certainly
possible with a combination of my patch and CONFIG_MEMORY_HOTREMOVE).
On Wed, 24 Nov 2010, Shaohui Zheng wrote:
> ah, a long time silence.
>
Sorry, last week included a holiday in the USA.
> Does somebody know the status of this patch, is it accepted by the maintainer?
> I am not in patch's CC list, so I will not get mail notice when the patch was
> accepted by the maintainer.
>
Neither of these patches have been merged anywhere yet, you're not missing
anything :) If/when Andrew picks it up, I'm quite certain he'll cc you on
it.
On Mon, 22 Nov 2010, Shaohui Zheng wrote:
> It is the improved solution from thread http://lkml.org/lkml/2010/11/18/3,
> our draft patch set all the nodes as possbile node, it wastes a lot of memory,
> the command line numa=possible=<N> seems to be an acceptable, and it is a optimization
> for our patch.
>
node_possible_map is a generic nodemask used throughout the kernel, but
its handling is highly dependent on the arch. This patch enables the
support for x86, I'd encourage anyone else interested in other archs to
look into adding the support for it as well (perhaps you can do it for
powerpc?).
> I like your active work attitude for the patch reviewing, it is real helpful to
> improve the patch quality.
>
Thanks, I'm happy to be involved!
On Sat, Nov 27, 2010 at 05:52:03PM -0800, David Rientjes wrote:
> On Sun, 21 Nov 2010, Greg KH wrote:
>
> > > Add an interface to allow new nodes to be added when performing memory
> > > hot-add. This provides a convenient interface to test memory hotplug
> > > notifier callbacks and surrounding hotplug code when new nodes are
> > > onlined without actually having a machine with such hotpluggable SRAT
> > > entries.
> > >
> > > This adds a new debugfs interface at /sys/kernel/debug/hotplug/add_node
> >
> > The rule for debugfs is "there are no rules", but perhaps you might want
> > to name "hotplug" a bit more specific for what you are doing? "hotplug"
> > means pretty much anything these days, so how about s/hotplug/node/
> > instead as that is what you are controlling.
> >
> > Just a suggestion...
> >
>
> Hmm, how strongly do you feel about that? There's nothing node specific
> in the memory hotplug code where this lives, so we'd probably have to
> define the dentry elsewhere and even then it would only needed for
> CONFIG_MEMORY_HOTPLUG.
>
> I personally don't see this as a node debugging but rather memory hotplug
> callback debugging.
Then name it as such, not the generic "hotplug" like you just did.
"mem_hotplug" would make sense, right?
thanks,
greg k-h
On Sat, 27 Nov 2010, Greg KH wrote:
> Then name it as such, not the generic "hotplug" like you just did.
> "mem_hotplug" would make sense, right?
>
Ok, Shaohui has taken my patches to post as part of the larger series and
I requested that the interface be changed from s/hotplug/mem_hotplug as
you suggested (and you should be cc'd). I agree it's a better name to
isolate memory hotplug debugging triggers from others.
Thanks Greg!