NUMA Hotplug Emulator(v5) - Feedbacks & Responses
Subsystems (9)
v5 cover NUMA Hotplug Emulator(v5) - Feedbacks & Responses
Hi, All
Thanks for all the review comments and feedbacks, This patcheset is v5 NUMA
Hotplug Emulator.
* PATCHSET INTRODUCTION
patch 1: Adds a numa=possible=<N> command line option to set an additional N nodes
as being possible for memory hotplug.
patch 2: Add node hotplug emulation, introduce debugfs node/add_node interface
patch 3: Abstract cpu register functions, make these interface friend for cpu
hotplug emulation
patch 4: Support cpu probe/release in x86, it provides a software method to hot
add/remove cpu with sysfs interface.
patch 5: Fake CPU socket with logical CPU on x86, to prevent the scheduling
domain to build the incorrect hierarchy.
patch 6: extend memory probe interface to support NUMA, we can add the memory to
a specified node with the interface.
patch 7: implement memory probe interface with debugfs
patch 8: Documentation.
* FEEDBACKS & RESPONSES
David: Suggests to use a flexible method to to do node hotplug emulation. After
review our 2 versions emulator implemetations, David provides a better solution
to solve both the flexibility and memory wasting issue.
Add numa=possible=<N> command line option, provide sysfs inteface /sys/devices/system/node/add_node interface, and move the inteface to debugfs /sys/kernel/debug/hotplug/add_node after hearing the voice from community.
Greg KH: move the interface from hotplug/add_node to node/add_node
Response: Accept David's node=possible=<n> command line options. After talking
with David, he agree to add his patch to our patchset, thanks David's solution(patch 1).
David's original interface /sys/kernel/debug/hotplug/add_node is not so clear for node hotplug emulation, we accept Greg's suggestion, move the interface to ndoe/add_node (patch 2)
Dave Hansen: For memory hotplug, Dave reminds Greg KH's advice, suggest us to use configfs replace
sysfs. After Dave knows that it is just for test purpose, Dave thinks debugfs should
be the best.
Response: memory probe sysfs interface already exists, I'd like to still keep it, and extend it
to support memory add on a specified node(patch 6).
We accepts Dave's suggestion, implement memory probe interface with debugfs(patch 7).
Signature · 10 lines
Thanks & Regards, Shaohui -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. 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:"[email protected]"> [email protected] </a>
PATCH v5 1/8 NUMA Hotplug Emulator: Add numa=possibe options
Signature · 11 lines
-- Thanks & Regards, Shaohui -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. 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:"[email protected]"> [email protected] </a>
Re: [1/8, v5] NUMA Hotplug Emulator: Add numa=possibe options
Quoted 6 lines · On Mon, 29 Nov 2010, [email protected] wrote:
Signature · 3 lines
-- Thanks & Regards, Shaohui
Shaohui, this patch doesn't appear to have made it, the email body is empty.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. 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:"[email protected]"> [email protected] </a>
Re: [1/8, v5] NUMA Hotplug Emulator: Add numa=possibe options
Quoted 11 lines · David Rientjes
Quoted 6 lines · On Mon, 29 Nov 2010, [email protected] wrote:
Signature · 3 lines
-- Thanks & Regards, ShaohuiShaohui, this patch doesn't appear to have made it, the email body is empty.
it is quilt's bug when generate emails, I already resend it. I will check each email content before sending it next time.
Signature · 9 lines
Thanks & Regards, Shaohui -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. 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:"[email protected]"> [email protected] </a>
PATCH v5 2/8 NUMA Hotplug Emulator: Add node hotplug emulation
In reply to [email protected]From: David Rientjes <[email protected]>
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/node/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.
---
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(-)
Documentation/memory-hotplug.txt +24 -0
@@ -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 "node/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/node/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
mm/memory_hotplug.c +59 -0
62 lines not on this page · raw message
Signature · 10 lines
Thanks & Regards, Shaohui -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. 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:"[email protected]"> [email protected] </a>
Re: [2/8, v5] NUMA Hotplug Emulator: Add node hotplug emulation
Quoted 8 lines · On Mon, 29 Nov 2010, [email protected] wrote:
From: David Rientjes <[email protected]>
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.
Quoted 5 lines
This adds a new debugfs interface at
/sys/kernel/debug/hotplug/add_nodethat 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.
Looks like you've changed some of the references in my changlog to node/add_node, but not others, such as the above. I'd actually much rather prefer to take Greg's latest suggestion of doing s/hotplug/mem_hotplug instead.
Would it be possible to repost the patch with that change?
Thanks!
Re: [2/8, v5] NUMA Hotplug Emulator: Add node hotplug emulation
Quoted 16 lines · David Rientjes
Quoted 8 lines · On Mon, 29 Nov 2010, [email protected] wrote:
From: David Rientjes <[email protected]>
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.
Quoted 5 lines
This adds a new debugfs interface at
/sys/kernel/debug/hotplug/add_nodethat 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.
Quoted 8 lines
Looks like you've changed some of the references in my changlog to node/add_node, but not others, such as the above. I'd actually much rather prefer to take Greg's latest suggestion of doing s/hotplug/mem_hotplug instead.
Would it be possible to repost the patch with that change?
Thanks!
We have two memory hotplug interfaces here:add_node: add a new NUMA node
probe: add memory section
so puting add_node to node/add_node and puting probe to memory/probe should make sense. it is similar with sysfs hierarchy.
if we want to move the add_node to mem_hotplug/add_node, I'd prefer to put the probe interface to mem_hotplug/probe since they are also related to memory hotplug.
I will include this change in next patchset.
Signature · 9 lines
Thanks & Regards, Shaohui -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. 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:"[email protected]"> [email protected] </a>
Re: [2/8, v5] NUMA Hotplug Emulator: Add node hotplug emulation
Quoted 4 lines · Shaohui Zheng
We have two memory hotplug interfaces here:
add_node: add a new NUMA node
probe: add memory section
Quoted 8 lines
so puting
add_nodeto node/add_node and puting probe to memory/probe should make sense. it is similar with sysfs hierarchy.if we want to move the
add_nodeto mem_hotplug/add_node, I'd prefer to put the probe interface to mem_hotplug/probe since they are also related to memory hotplug.I will include this change in next patchset.
No, please don't move the 'probe' trigger to debugfs; hotadding memory should not depend on CONFIG_DEBUG_FS. Node hotplug emulation _is_ a debugging function and can therefore be defined in debugfs as I did but with a s/hotplug/mem_hotplug change that Greg suggested.
Re: [2/8, v5] NUMA Hotplug Emulator: Add node hotplug emulation
Quoted 12 lines · David Rientjes
Quoted 10 lines · Shaohui Zheng
We have two memory hotplug interfaces here:
add_node: add a new NUMA node
probe: add memory sectionso puting
add_nodeto node/add_node and puting probe to memory/probe should make sense. it is similar with sysfs hierarchy.if we want to move the
add_nodeto mem_hotplug/add_node, I'd prefer to put the probe interface to mem_hotplug/probe since they are also related to memory hotplug.
Quoted 7 lines
Quoted 2 lines
I will include this change in next patchset.
No, please don't move the 'probe' trigger to debugfs; hotadding memory should not depend on
CONFIG_DEBUG_FS. Node hotplug emulation _is_ a debugging function and can therefore be defined in debugfs as I did but with a s/hotplug/mem_hotplug change that Greg suggested.
David,
we provide both debugfs and sysfs interface for memory probe, the sysfs
interface is always available. For debugfs interface, it depends on CONFIG_DEBUG_FS.
we can also think that memory hotplug emulation _is_ a debuging function,
so we accept Dave's suggestion to provide debugfs interface.
Signature · 2 lines
Thanks & Regards, Shaohui
Re: [2/8, v5] NUMA Hotplug Emulator: Add node hotplug emulation
Quoted 6 lines · Shaohui Zheng
David,
we provide both debugfs and sysfs interface for memory probe, the sysfs
interface is always available. For debugfs interface, it depends onCONFIG_DEBUG_FS.
we can also think that memory hotplug emulation _is_ a debuging function,
so we accept Dave's suggestion to provide debugfs interface.
We don't need two different interfaces, one in sysfs and one in debugfs, to hotplug memory.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. 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:"[email protected]"> [email protected] </a>
PATCH v5 3/8 NUMA Hotplug Emulation: Abstract cpu register functions
In reply to [email protected]From: Shaohui Zheng <[email protected]>
Abstract cpu register functions, provide a more flexible interface register_cpu_node, the new interface provides convenience to add cpu to a specified node, we can use it to add a cpu to a fake node.
---
arch/x86/include/asm/cpu.h +1 -0
@@ -27,6 +27,7 @@#ifdef CONFIG_HOTPLUG_CPU extern int arch_register_cpu (int num); +extern int arch_register_cpu_node (int num,int nid);extern void arch_unregister_cpu (int );#endif
arch/x86/kernel/topology.c +9 -0
@@ -52,6 +52,15 @@ }EXPORT_SYMBOL (arch_register_cpu); +int __ref arch_register_cpu_node (int num,int nid) +{ +if (num) +per_cpu (cpu_devices, num).cpu.hotpluggable =1 ; + +return register_cpu_node (&per_cpu (cpu_devices, num).cpu, num, nid); +} +EXPORT_SYMBOL (arch_register_cpu_node); +void arch_unregister_cpu (int num) {unregister_cpu (&per_cpu (cpu_devices, num).cpu);
drivers/base/cpu.c +5 -4
@@ -208,17 +208,18 @@ static SYSDEV_CLASS_ATTR(offline, 0444, print_cpus_offline, NULL);/* -* register_cpu - Setup a sysfs device for a CPU. +* register_cpu_node - Setup a sysfs device for a CPU. * @cpu - cpu->hotpluggable field set to 1 will generate a control file in * sysfs for this CPU. * @num - CPU number to use when creating the device. +* @nid - Node ID to use, if any. * * Initialize and register the CPU device. */ -int __cpuinit register_cpu (struct cpu *cpu,int num) +int __cpuinit register_cpu_node (struct cpu *cpu,int num,int nid) {int error; - cpu->node_id =cpu_to_node (num); + cpu->node_id = nid; cpu->sysdev.id = num; cpu->sysdev.cls = &cpu_sysdev_class;
@@ -229,7 +230,7 @@if (!error)per_cpu (cpu_sys_devices, num) = &cpu->sysdev;if (!error) -register_cpu_under_node (num,cpu_to_node (num)); +register_cpu_under_node (num, nid);#ifdef CONFIG_KEXEC if (!error)
include/linux/cpu.h +7 -1
@@ -30,7 +30,13 @@struct sys_device sysdev; }; -extern int register_cpu (struct cpu *cpu,int num); +extern int register_cpu_node (struct cpu *cpu,int num,int nid); + +static inline int register_cpu (struct cpu *cpu,int num) +{ +return register_cpu_node (cpu, num,cpu_to_node (num)); +} +extern struct sys_device *get_cpu_sysdev (unsigned cpu);extern int cpu_add_sysdev_attr (struct sysdev_attribute *attr);
Signature · 10 lines
Thanks & Regards, Shaohui -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. 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:"[email protected]"> [email protected] </a>
PATCH v5 4/8 NUMA Hotplug Emulator: support cpu probe/release in x86_64
In reply to [email protected]From: Shaohui Zheng <[email protected]>
CPU physical hot-add/hot-remove are supported on some hardwares, and it was already supported in current linux kernel. CPU Hotplug Emulator provides a mechanism to emulate the process with software method. It can be used for testing or debuging purpose.
CPU physical hotplug is different with logical CPU online/offline. Logical online/offline is controled by interface /sys/device/cpu/cpuX/online. CPU hotplug emulator uses probe/release interface. It becomes possible to do cpu hotplug automation and stress
Add cpu interface probe/release under sysfs for x86_64. User can use this interface to emulate the cpu hot-add and hot-remove process.
Directive:
*) Reserve CPU thru grub parameter like:
maxcpus=4
the rest CPUs will not be initiliazed.
*) Probe CPU
we can use the probe interface to hot-add new CPUs:
echo nid > /sys/devices/system/cpu/probe
*) Release a CPU
echo cpu > /sys/devices/system/cpu/release
A reserved CPU will be hot-added to the specified node.
1) nid == 0, the CPU will be added to the real node which the CPU should be in
2) nid != 0, add the CPU to node nid even through it is a fake node.
---
arch/x86/kernel/acpi/boot.c +36 -0
@@ -647,8 +647,44 @@ }EXPORT_SYMBOL (acpi_map_lsapic); +#ifdef CONFIG_ARCH_CPU_PROBE_RELEASE +static void acpi_map_cpu2node_emu (int cpu,int physid,int nid) +{ +#ifdef CONFIG_ACPI_NUMA +#ifdef CONFIG_X86_64 + apicid_to_node[physid] = nid; +numa_set_node (cpu, nid); +#else /* CONFIG_X86_32 */ + apicid_2_node[physid] = nid; + cpu_to_node_map[cpu] = nid; +#endif +#endif +} + +static u16 cpu_to_apicid_saved[CONFIG_NR_CPUS ]; +int __ref acpi_map_lsapic_emu (int pcpu,int nid) +{ +/* backup cpu apicid to array cpu_to_apicid_saved */ +if (cpu_to_apicid_saved[pcpu] ==0 && +per_cpu (x86_cpu_to_apicid, pcpu) !=BAD_APICID ) + cpu_to_apicid_saved[pcpu] =per_cpu (x86_cpu_to_apicid, pcpu); + +per_cpu (x86_cpu_to_apicid, pcpu) = cpu_to_apicid_saved[pcpu]; +acpi_map_cpu2node_emu (pcpu,per_cpu (x86_cpu_to_apicid, pcpu), nid); + +return pcpu; +} +EXPORT_SYMBOL (acpi_map_lsapic_emu); +#endif +int acpi_unmap_lsapic (int cpu) { +#ifdef CONFIG_ARCH_CPU_PROBE_RELEASE +/* backup cpu apicid to array cpu_to_apicid_saved */ +if (cpu_to_apicid_saved[cpu] ==0 && +per_cpu (x86_cpu_to_apicid, cpu) !=BAD_APICID ) + cpu_to_apicid_saved[cpu] =per_cpu (x86_cpu_to_apicid, cpu); +#endif per_cpu (x86_cpu_to_apicid, cpu) =-1 ;set_cpu_present (cpu, false); num_processors--;
arch/x86/kernel/smpboot.c +0 -2
@@ -107,8 +107,6 @@ mutex_unlock(&x86_cpu_hotplug_driver_mutex); } -ssize_t arch_cpu_probe (const char *buf,size_t count) {return -1 ; } -ssize_t arch_cpu_release (const char *buf,size_t count) {return -1 ; }#else static struct task_struct *idle_thread_array[NR_CPUS ]__cpuinitdata ;#define get_idle_for_cpu (x) (idle_thread_array[(x)])
arch/x86/kernel/topology.c +79 -2
99 lines not on this page · raw message
arch/x86/mm/numa_64.c +14 -0
@@ -12,6 +12,7 @@#include <linux/module.h> #include <linux/nodemask.h> #include <linux/sched.h> +#include <linux/cpu.h> #include <asm/e820.h> #include <asm/proto.h>
@@ -785,6 +786,19 @@ }#endif +#ifdef CONFIG_ARCH_CPU_PROBE_RELEASE +static __init int cpu_hpe_setup (char *opt) +{ +if (!opt) +return -EINVAL ; + +if (!strncmp (opt,"on" ,2 ) || !strncmp (opt,"1" ,1 )) + cpu_hpe_on =1 ; + +return 0 ; +} +early_param ("cpu_hpe" , cpu_hpe_setup); +#endif /* CONFIG_ARCH_CPU_PROBE_RELEASE */ void __cpuinit numa_set_node (int cpu,int node) {
drivers/acpi/processor_driver.c +9 -0
@@ -530,6 +530,14 @@ goto err_free_cpumask; sysdev =get_cpu_sysdev (pr->id); +/* +* Reserve cpu for hotplug emulation, the reserved cpu can be hot-added +* throu the cpu probe interface. Return directly. +*/ +if (sysdev ==NULL ) { + goto out; + } +if (sysfs_create_link (&device->dev.kobj, &sysdev->kobj,"sysdev" )) { result = -EFAULT ; goto err_remove_fs;
@@ -570,6 +578,7 @@ goto err_remove_sysfs; } +out:return 0 ; err_remove_sysfs:
drivers/base/cpu.c +7 -1
@@ -22,9 +22,15 @@ };EXPORT_SYMBOL (cpu_sysdev_class); -static DEFINE_PER_CPU(struct sys_device *, cpu_sys_devices); +DEFINE_PER_CPU(struct sys_device *, cpu_sys_devices);#ifdef CONFIG_HOTPLUG_CPU +/* +* cpu_hpe_on is a switch to enable/disable cpu hotplug emulation. it is +* disabled in default, we can enable it throu grub parameter cpu_hpe=on +*/ +int cpu_hpe_on; +static ssize_t show_online (struct sys_device *dev,struct sysdev_attribute *attr,char *buf) {
include/linux/acpi.h +1 -0
@@ -102,6 +102,7 @@#ifdef CONFIG_ACPI_HOTPLUG_CPU /* Arch dependent functions for cpu hotplug support */ int acpi_map_lsapic (acpi_handle handle,int *pcpu); +int acpi_map_lsapic_emu (int pcpu,int nid);int acpi_unmap_lsapic (int cpu);#endif /* CONFIG_ACPI_HOTPLUG_CPU */
include/linux/cpu.h +4 -0
@@ -30,6 +30,8 @@struct sys_device sysdev; }; +DECLARE_PER_CPU(struct sys_device *, cpu_sys_devices); +extern int register_cpu_node (struct cpu *cpu,int num,int nid);static inline int register_cpu (struct cpu *cpu,int num)
@@ -149,6 +151,7 @@#define register_hotcpu_notifier (nb) register_cpu_notifier(nb)#define unregister_hotcpu_notifier (nb) unregister_cpu_notifier(nb)int cpu_down (unsigned int cpu); +extern int cpu_hpe_on;#ifdef CONFIG_ARCH_CPU_PROBE_RELEASE extern void cpu_hotplug_driver_lock (void );
@@ -171,6 +174,7 @@/* These aren't inline functions due to a GCC bug. */ #define register_hotcpu_notifier (nb) ({ (void)(nb); 0; })#define unregister_hotcpu_notifier (nb) ({ (void)(nb); }) +static int cpu_hpe_on;#endif /* CONFIG_HOTPLUG_CPU */ #ifdef CONFIG_PM_SLEEP_SMP
Documentation/x86/x86_64/boot-options.txt +6 -0
@@ -316,3 +316,9 @@ Do not use GB pages for kernel direct mappings. gbpages Use GB pages for kernel direct mappings. + cpu_hpe=on/off + Enable/disable CPU hotplug emulation with software method. When cpu_hpe=on, + sysfs provides probe/release interface to hot add/remove CPUs dynamically. + We can use maxcpus=<N> to reserve CPUs. + This option is disabled by default. +
Signature · 10 lines
Thanks & Regards, Shaohui -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. 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:"[email protected]"> [email protected] </a>
PATCH v5 5/8 NUMA Hotplug Emulator: Fake CPU socket with logical CPU on x86
In reply to [email protected]From: Shaohui Zheng <[email protected]>
When hotplug a CPU with emulator, we are using a logical CPU to emulate the CPU hotplug process. For the CPU supported SMT, some logical CPUs are in the same socket, but it may located in different NUMA node after we have emulator. it misleads the scheduling domain to build the incorrect hierarchy, and it causes the following call trace when rebalance the scheduling domain:
divide error: 0000 [#1] SMP
last sysfs file: /sys/devices/system/cpu/cpu8/online CPU 0
Modules linked in: fbcon tileblit font bitblit softcursor radeon ttm drm_kms_helper e1000e usbhid via_rhine mii drm i2c_algo_bit igb dca Pid: 0, comm: swapper Not tainted 2.6.32hpe #78 X8DTN RIP: 0010:[<ffffffff81051da5>] [<ffffffff81051da5>] find_busiest_group+0x6c5/0xa10 RSP: 0018:ffff880028203c30 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000015ac0 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffff880277e8cfa0 RDI: 0000000000000000 RBP: ffff880028203dc0 R08: ffff880277e8cfa0 R09: 0000000000000040 R10: 0000000000000000 R11: 0000000000000001 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff880028200000(0000) knlGS:0000000000000000 CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b CR2: 00007f16cfc85770 CR3: 0000000001001000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process swapper (pid: 0, threadinfo ffffffff81822000, task ffffffff8184a600) Stack: ffff880028203d60 ffff880028203cd0 ffff8801c204ff08 ffff880028203e38 <0> 0101ffff81018c59 ffff880028203e44 00000001810806bd ffff8801c204fe00 <0> 0000000528200000 ffffffff00000000 0000000000000018 0000000000015ac0 Call Trace: <IRQ> [<ffffffff81088ee0>] ? tick_dev_program_event+0x40/0xd0 [<ffffffff81053b2c>] rebalance_domains+0x17c/0x570 [<ffffffff81018c89>] ? read_tsc+0x9/0x20 [<ffffffff81088ee0>] ? tick_dev_program_event+0x40/0xd0 [<ffffffff810569ed>] run_rebalance_domains+0xbd/0xf0 [<ffffffff8106471f>] __do_softirq+0xaf/0x1e0 [<ffffffff810b7d18>] ? handle_IRQ_event+0x58/0x160 [<ffffffff810130ac>] call_softirq+0x1c/0x30 [<ffffffff81014a85>] do_softirq+0x65/0xa0 [<ffffffff810645cd>] irq_exit+0x7d/0x90 [<ffffffff81013ff0>] do_IRQ+0x70/0xe0 [<ffffffff810128d3>] ret_from_intr+0x0/0x11 <EOI> [<ffffffff8133387f>] ? acpi_idle_enter_bm+0x281/0x2b5 [<ffffffff81333878>] ? acpi_idle_enter_bm+0x27a/0x2b5 [<ffffffff8145dc8f>] ? cpuidle_idle_call+0x9f/0x130 [<ffffffff81010e2b>] ? cpu_idle+0xab/0x100 [<ffffffff8158aee6>] ? rest_init+0x66/0x70 [<ffffffff81905d90>] ? start_kernel+0x3e3/0x3ef [<ffffffff8190533a>] ? x86_64_start_reservations+0x125/0x129 [<ffffffff81905438>] ? x86_64_start_kernel+0xfa/0x109 Code: 00 00 e9 4c fb ff ff 0f 1f 80 00 00 00 00 48 8b b5 d8 fe ff ff 48 8b 45 a8 4d 29 ef 8b 56 08 48 c1 e0 0a 49 89 f0 48 89 d7 31 d2 <48> f7 f7 31 d2 48 89 45 a0 8b 76 08 4c 89 f0 48 c1 e0 0a 48 f7 RIP [<ffffffff81051da5>] find_busiest_group+0x6c5/0xa10 RSP <ffff880028203c30>
Solution:
We put the logical CPU into a fake CPU socket, and assign it an unique
phys_proc_id. For the fake socket, we put one logical CPU in only. This
method fixes the above bug.
---
arch/x86/include/asm/processor.h +9 -0
@@ -113,6 +113,15 @@/* Index into per_cpu list: */ u16 cpu_index;#endif + +#ifdef CONFIG_ARCH_CPU_PROBE_RELEASE +/* +* Use a logic cpu to emulate a physical cpu's hotplug. We put the +* logical cpu into a fake socket, assign a fake physical id to it, +* and create a fake core. +*/ +__u8 cpu_probe_on;/* A flag to enable cpu probe/release */ +#endif } __attribute__((__aligned__(SMP_CACHE_BYTES)));#define X86_VENDOR_INTEL 0
arch/x86/kernel/smpboot.c +24 -1
@@ -97,6 +97,7 @@*/ static DEFINE_MUTEX (x86_cpu_hotplug_driver_mutex); +#ifdef CONFIG_ARCH_CPU_PROBE_RELEASE void cpu_hotplug_driver_lock () {mutex_lock (&x86_cpu_hotplug_driver_mutex);
@@ -106,6 +107,7 @@ {mutex_unlock (&x86_cpu_hotplug_driver_mutex); } +#endif #else static struct task_struct *idle_thread_array[NR_CPUS ]__cpuinitdata ;
@@ -198,6 +200,8 @@ {int cpuid, phys_id;unsigned long timeout; +u8 cpu_probe_on =0 ; +struct cpuinfo_x86 *c;/* * If waken up by an INIT in an 82489DX configuration
@@ -277,7 +281,20 @@/* * Save our processor parameters */ + c = &cpu_data (cpuid); +#ifdef CONFIG_ARCH_CPU_PROBE_RELEASE + cpu_probe_on = c->cpu_probe_on; + phys_id = c->phys_proc_id; +#endif +smp_store_cpu_info (cpuid); +#ifdef CONFIG_ARCH_CPU_PROBE_RELEASE +if (cpu_probe_on) { + c->phys_proc_id = phys_id;/* restore the fake phys_proc_id */ + c->cpu_core_id =0 ;/* force the logical cpu to core 0 */ + c->cpu_probe_on = cpu_probe_on; + } +#endif notify_cpu_starting (cpuid);
@@ -400,6 +417,11 @@ {int i;struct cpuinfo_x86 *c = &cpu_data (cpu); +int cpu_probe_on =0 ; + +#ifdef CONFIG_ARCH_CPU_PROBE_RELEASE + cpu_probe_on = c->cpu_probe_on; +#endif cpumask_set_cpu (cpu, cpu_sibling_setup_mask);
@@ -431,7 +453,8 @@for_each_cpu (i, cpu_sibling_setup_mask) {if (per_cpu (cpu_llc_id, cpu) !=BAD_APICID && -per_cpu (cpu_llc_id, cpu) ==per_cpu (cpu_llc_id, i)) { +per_cpu (cpu_llc_id, cpu) ==per_cpu (cpu_llc_id, i) && + cpu_probe_on ==0 ) {cpumask_set_cpu (i, c->llc_shared_map);cpumask_set_cpu (cpu,cpu_data (i).llc_shared_map); }
arch/x86/kernel/topology.c +34 -0
@@ -70,6 +70,36 @@ }EXPORT_SYMBOL (arch_unregister_cpu); +#ifdef CONFIG_ARCH_CPU_PROBE_RELEASE +/* +* Put the logical cpu into a new sokect, and encapsule it into core 0. +*/ +static void fake_cpu_socket_info (int cpu) +{ +struct cpuinfo_x86 *c = &cpu_data (cpu); +int i, phys_id =0 ; + +/* calculate the max phys_id */ +for_each_present_cpu (i) { +struct cpuinfo_x86 *c = &cpu_data (i); +if (phys_id < c->phys_proc_id) + phys_id = c->phys_proc_id; + } + + c->phys_proc_id = phys_id +1 ;/* pick up a unused phys_proc_id */ + c->cpu_core_id =0 ;/* always put the logical cpu to core 0 */ + c->cpu_probe_on =1 ; +} + +static void clear_cpu_socket_info (int cpu) +{ +struct cpuinfo_x86 *c = &cpu_data (cpu); + c->phys_proc_id =0 ; + c->cpu_core_id =0 ; + c->cpu_probe_on =0 ; +} + +ssize_t arch_cpu_probe (const char *buf,size_t count) {int nid =0 ;
@@ -109,6 +139,7 @@/* register cpu */ arch_register_cpu_node (selected, nid);acpi_map_lsapic_emu (selected, nid); +fake_cpu_socket_info (selected);return count; }
@@ -132,10 +163,13 @@arch_unregister_cpu (cpu);acpi_unmap_lsapic (cpu); +clear_cpu_socket_info (cpu); +set_cpu_present (cpu, true); return count; }EXPORT_SYMBOL (arch_cpu_release); +#endif CONFIG_ARCH_CPU_PROBE_RELEASE#else /* CONFIG_HOTPLUG_CPU */
Signature · 10 lines
Thanks & Regards, Shaohui -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. 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:"[email protected]"> [email protected] </a>
PATCH v5 6/8 From: Shaohui Zheng <[email protected]>
In reply to [email protected]Subject: [6/8, v5] NUMA Hotplug Emulator: extend memory probe interface to support NUMA
Extend memory probe interface to support an extra paramter nid, the reserved memory can be added into this node if node exists.
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
it is more explicit to show meaning of the parameters.
---
arch/x86/Kconfig +0 -4
@@ -1276,10 +1276,6 @@ def_bool y depends on ARCH_SPARSEMEM_ENABLE -config ARCH_MEMORY_PROBE - def_bool X86_64 - depends on MEMORY_HOTPLUG - config ILLEGAL_POINTER_VALUE hex default 0 if X86_32
drivers/base/memory.c +59 -10
86 lines not on this page · raw message
mm/Kconfig +11 -0
@@ -174,6 +174,17 @@ default "999999" if DEBUG_SPINLOCK || DEBUG_LOCK_ALLOC default "4" +config ARCH_MEMORY_PROBE + def_bool y + bool "Memory hotplug emulation" + depends on MEMORY_HOTPLUG + ---help--- + Enable memory hotplug emulation. Reserve memory with grub parameter + "mem=N"(such as mem=1024M), where N is the initial memory size, the + rest physical memory will be removed from e820 table; the memory probe + interface is for memory hot-add to specified node in software method. + This is for debuging and testing purpose + # # support for memory compaction config COMPACTION
include/linux/memory_hotplug.h +8 -0
@@ -211,6 +211,14 @@extern void sparse_remove_one_section (struct zone *zone,struct mem_section *ms);extern struct page *sparse_decode_mem_map (unsigned long coded_mem_map,unsigned long pnum); +#ifdef CONFIG_ARCH_MEMORY_PROBE +extern ssize_t parse_memory_probe_store (const char *buf,size_t count); +#else +static inline ssize_t parse_memory_probe_store (const char *buf,size_t count) +{ +return 0 ; +} +#endif /* CONFIG_ARCH_MEMORY_PROBE */ #ifdef CONFIG_ARCH_MEMORY_PROBE extern ssize_t parse_memory_probe_store (const char *buf,size_t count);
Signature · 10 lines
Thanks & Regards, Shaohui -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. 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:"[email protected]"> [email protected] </a>
PATCH v5 7/8 NUMA Hotplug Emulator: implement debugfs interface for memory probe
In reply to [email protected]From: Shaohui Zheng <[email protected]>
Implement a debugfs inteface /sys/kernel/debug/memory/probe for meomory hotplug emulation. it accepts the same parameters like /sys/devices/system/memory/probe.
Document the interface usage to file Documentation/memory-hotplug.txt.
--
mm/memory_hotplug.c +31 -0
@@ -982,4 +982,35 @@ }module_init (node_debug_init); + +#ifdef CONFIG_ARCH_MEMORY_PROBE +static struct dentry *memory_debug_root; + +static ssize_t debug_memory_probe_store (struct file *file,const char __user *buf, +size_t count,loff_t *ppos) +{ +return parse_memory_probe_store (buf, count); +} + +static const struct file_operations memory_probe_file_ops = { + .write = debug_memory_probe_store, + .llseek = generic_file_llseek, +}; + +static int __init memory_debug_init (void ) +{ + memory_debug_root =debugfs_create_dir ("memory" ,NULL ); +if (!memory_debug_root) +return -ENOMEM ; + +if (!debugfs_create_file ("probe" ,S_IWUSR , memory_debug_root, +NULL , &memory_probe_file_ops)) +return -ENOMEM ; + +return 0 ; +} + +module_init (memory_debug_init); + +#endif /* CONFIG_ARCH_MEMORY_PROBE */ #endif /* CONFIG_DEBUG_FS */
Documentation/memory-hotplug.txt +21 -5
@@ -198,23 +198,39 @@ In some environments, especially virtualized environment, firmware will not notify memory hotplug event to the kernel. For such environment, "probe" interface is supported. This interface depends on CONFIG_ARCH_MEMORY_PROBE. +It can be also used for physical memory hotplug emulation. -Now, CONFIG_ARCH_MEMORY_PROBE is supported only by powerpc but it does not -contain highly architecture codes. Please add config if you need "probe" +Now, CONFIG_ARCH_MEMORY_PROBE is supported by powerpc and x86_64, but it does +not contain highly architecture codes. Please add config if you need "probe" interface. -Probe interface is located at -/sys/devices/system/memory/probe +We have both sysfs and debugfs interface for memory probe. They are located at +/sys/devices/system/memory/probe (sysfs) and /sys/kernel/debug/memory/probe +(debugfs), We can try any of them, they accpet the same parameters. You can tell the physical address of new memory to the kernel by -% echo start_address_of_new_memory > /sys/devices/system/memory/probe +% echo start_address_of_new_memory > memory/probe Then, [start_address_of_new_memory, start_address_of_new_memory + section_size) memory range is hot-added. In this case, hotplug script is not called (in current implementation). You'll have to online memory by yourself. Please see "How to online memory" in this text. +memory/probe interface accepts more flexible parameters, for example: + +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 + +Another format suggested by Dave Hansen: + + echo physical_address=0x40000000 numa_node=3 > memory/probe 4.3 Node hotplug emulation ------------
Signature · 10 lines
Thanks & Regards, Shaohui -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. 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:"[email protected]"> [email protected] </a>
PATCH v5 8/8 NUMA Hotplug Emulator: documentation
In reply to [email protected]From: Shaohui Zheng <[email protected]>
add a text file Documentation/x86/x86_64/numa_hotplug_emulator.txt to explain the usage for the hotplug emulator.
---
Documentation/x86/x86_64/numa_hotplug_emulator.txt new file +103 -0
@@ -0,0 +1,103 @@ +NUMA Hotplug Emulator for x86_64 +--------------------------------------------------- + +NUMA hotplug emulator is able to emulate NUMA Node Hotplug +thru a pure software way. It intends to help people easily debug +and test node/CPU/memory hotplug related stuff on a +none-NUMA-hotplug-support machine, even a UMA machine and virtual +environment. + +1) Node hotplug emulation: + +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. + +For emulation on x86, 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/node/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. ] + +2) CPU hotplug emulation: + +The emulator reserve CPUs throu grub parameter, the reserved CPUs can be +hot-add/hot-remove in software method, it emulates the process of physical +cpu hotplug. + +When hotplugging a CPU with emulator, we are using a logical CPU to emulate the CPU +socket hotplug process. For the CPU supported SMT, some logical CPUs are in the +same socket, but it may located in different NUMA node after we have emulator. +We put the logical CPU into a fake CPU socket, and assign it a unique +phys_proc_id. For the fake socket, we put one logical CPU in only. + + - to hide CPUs + - Using boot option "maxcpus=N" hide CPUs + N is the number of CPUs to initialize; the reset will be hidden. + - Using boot option "cpu_hpe=on" to enable CPU hotplug emulation + when cpu_hpe is enabled, the rest CPUs will not be initialized + + - to hot-add CPU to node + $ echo nid > cpu/probe + + - to hot-remove CPU + $ echo nid > cpu/release + +3) Memory hotplug emulation: + +The emulator reserves memory before OS boots, the reserved memory region is +removed from e820 table, and they can be hot-added via the probe interface. +this interface was extended to support adding memory to the specified node. It +maintains backwards compatibility. + +The difficulty of Memory Release is well-known, we have no plan for it until now. + + - reserve memory thru a kernel boot paramter + mem=1024m + + - add a memory section to node 3 + $ echo 0x40000000,3 > memory/probe + OR + $ echo 1024m,3 > memory/probe + OR + $ echo "physical_address=0x40000000 numa_node=3" > memory/probe + +4) Script for hotplug testing + +These scripts provides convenience when we hot-add memory/cpu in batch. + +- Online all memory sections: +for m in /sys/devices/system/memory/memory*; +do + echo online > $m/state; +done + +- CPU Online: +for c in /sys/devices/system/cpu/cpu*; +do + echo 1 > $c/online; +done + +- Haicheng Li <[email protected]> +- Shaohui Zheng <[email protected]> + Nov 2010
Signature · 10 lines
Thanks & Regards, Shaohui -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. 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:"[email protected]"> [email protected] </a>
Re: [8/8, v5] NUMA Hotplug Emulator: documentation
Quoted 4 lines · On Mon, 29 Nov 2010 17:17:58 +0800, [email protected] said:
From: Shaohui Zheng <[email protected]>
add a text file
Documentation/x86/x86_64/numa_hotplug_emulator.txtto explain the usage for the hotplug emulator.
Can you renumber this to 1/8 if you resubmit it? It helps code review if you already know what it's *intended* to do beforehand. It also helps drinking from the lkml firehose if you can read 0/N and 1/N and know if it's something you want to review, otherwise you read 0/N, have to go find N/N, read that, then go back and delete 1/N through N-1/N.
(Sometimes, the 0/N cover isn't enough - reading the documentation actually fills in enough blanks to make you go "Wow, this *is* applicable to something I'm working on...")
Re: [8/8, v5] NUMA Hotplug Emulator: documentation
Quoted 12 lines · On Mon, Nov 29, 2010 at 01:19:16PM -0500, [email protected] wrote:
Quoted 4 lines · On Mon, 29 Nov 2010 17:17:58 +0800, [email protected] said:
From: Shaohui Zheng <[email protected]>
add a text file
Documentation/x86/x86_64/numa_hotplug_emulator.txtto explain the usage for the hotplug emulator.Can you renumber this to 1/8 if you resubmit it? It helps code review if you already know what it's *intended* to do beforehand. It also helps drinking from the lkml firehose if you can read 0/N and 1/N and know if it's something you want to review, otherwise you read 0/N, have to go find N/N, read that, then go back and delete 1/N through N-1/N.
Quoted 3 lines
(Sometimes, the 0/N cover isn't enough - reading the documentation actually fills in enough blanks to make you go "Wow, this *is* applicable to something I'm working on...")
When I send the previous version, I always add the full documentation in 0/N patches. The feedbacks, suggestions, and modifications are all included in 0/N patch. it makes it as a very long text, so I decide to remove the full documentation from 0/N since we already send these docs in early version, it get the 0/N patch
much smaller.
I will still keep the full documentation in 0/N, and renumber 8/8 to 1/8. Thanks
for the remind.
Signature · 9 lines
Thanks & Regards, Shaohui -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. 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:"[email protected]"> [email protected] </a>
Re: [8/8, v5] NUMA Hotplug Emulator: documentation
In reply to [email protected]Quoted 4 lines · On Mon, 29 Nov 2010, [email protected] wrote:
+- Haicheng Li <[email protected]> +- Shaohui Zheng <[email protected]> + Nov 2010
Didn't I write half of this document?
Re: [8/8, v5] NUMA Hotplug Emulator: documentation
Quoted 8 lines · David Rientjes
Quoted 4 lines · On Mon, 29 Nov 2010, [email protected] wrote:
+- Haicheng Li <[email protected]> +- Shaohui Zheng <[email protected]> + Nov 2010Didn't I write half of this document?
I miss it, I will your name into the list :).
Signature · 9 lines
Thanks & Regards, Shaohui -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. 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:"[email protected]"> [email protected] </a>