2/5 in support of hot-add memory x86_64 create arch_find_node
Subsystems (3)
PATCH 1/1 2/5 in support of hot-add memory x86_64 create arch_find_node
With the advent of the new ACPI hot-plug memory driver and mechanism
is needed to deal with ACPI add memory events that do not contain the pxm (node) information. I do not believe that the add-event is required to contain this information so I create a arch_find_node generic layer used in the generic add_memory function.
If add_memory is called with node < 0 arch_find_node is invoked to
fine the correct node to add the memory. This created the generic construct of arch_find_node.
This was built against 2.6.18-rc2.
include/linux/memory_hotplug.h +5 -1
@@ -132,7 +132,11 @@ }#endif /* CONFIG_NUMA */ #endif /* CONFIG_HAVE_ARCH_NODEDATA_EXTENSION */ - +#ifdef CONFIG_ARCH_FIND_NODE +extern int arch_find_node (unsigned long ,unsigned long ); +#else +static inline int arch_find_node (unsigned long a,unsigned long b) {return 0 ;} +#endif #else /* ! CONFIG_MEMORY_HOTPLUG */ /* * Stub functions for when hotplug is off
mm/memory_hotplug.c +7 -2
@@ -233,12 +233,17 @@ -int add_memory (int nid,u64 start,u64 size) +int add_memory (int node,u64 start,u64 size) {pg_data_t *pgdat =NULL ;int new_pgdat =0 ; -int ret; +int ret,nid; +if (node <0 ) + nid =arch_find_node (start,size); +else + nid = node; +if (!node_online (nid)) { pgdat =hotadd_new_pgdat (nid, start);if (!pgdat)
Quoted 9 lines · keith mannthey
With the advent of the new ACPI hot-plug memory driver and mechanism
is needed to deal with ACPI add memory events that do not contain the pxm (node) information. I do not believe that the add-event is required to contain this information so I create aarch_find_nodegeneric layer used in the genericadd_memoryfunction.If
add_memoryis called with node < 0arch_find_nodeis invoked to
fine the correct node to add the memory. This created the generic construct ofarch_find_node.
It would be cleaner to always call add_memory from architecture specific code instead of such ugly hooks
-Andi
Quoted 7 lines · Andi Kleen
Quoted 6 lines · keith mannthey
With the advent of the new ACPI hot-plug memory driver and mechanism
is needed to deal with ACPI add memory events that do not contain the pxm (node) information. I do not believe that the add-event is required to contain this information so I create aarch_find_nodegeneric layer used in the genericadd_memoryfunction.
Quoted 6 lines
Quoted 3 lines
If
add_memoryis called with node < 0arch_find_nodeis invoked to
fine the correct node to add the memory. This created the generic construct ofarch_find_node.It would be cleaner to always call
add_memoryfrom architecture specific code instead of such ugly hooks
Since 2.6.18 it goes
acpi (generic calling add_memory)add_memory (generic)arch_add_memory (x86_64)__add_pages (generic)
The generic add_memory call is good as it does the dynamic pgdat allocation for new nodes. The generic add_memory call need the correct node infomation.
Do you think we should do
acpi (generic calling add_memory)arch_pre_add_memory? (x86_64)add_memory (generic)arch_add_memory (x86_64)__add_pages (generic)
?
It would just create a function hook.
Thanks,
Keith
Quoted 7 lines · On Sat, 29 Jul 2006 18:25:15 +0200 Andi Kleen <[email protected]> wrote:
Quoted 6 lines · keith mannthey
With the advent of the new ACPI hot-plug memory driver and mechanism
is needed to deal with ACPI add memory events that do not contain the pxm (node) information. I do not believe that the add-event is required to contain this information so I create aarch_find_nodegeneric layer used in the genericadd_memoryfunction.
Quoted 7 lines
Quoted 3 lines
If
add_memoryis called with node < 0arch_find_nodeis invoked to
fine the correct node to add the memory. This created the generic construct ofarch_find_node.It would be cleaner to always call
add_memoryfrom architecture specific code instead of such ugly hooks
Hi, Keith
I don't like insert such a check (nid < 0) in add_memory(), either. Could you add it before calling add_memory() ?
(for example, find_pxm parh in acpi's add memory code.)
-Kame
Quoted 14 lines
Quoted 11 lines · On Sat, 29 Jul 2006 18:25:15 +0200 Andi Kleen <[email protected]> wrote:
Quoted 9 lines · keith mannthey
With the advent of the new ACPI hot-plug memory driver and mechanism
is needed to deal with ACPI add memory events that do not contain the pxm (node) information. I do not believe that the add-event is required to contain this information so I create aarch_find_nodegeneric layer used in the genericadd_memoryfunction.If
add_memoryis called with node < 0arch_find_nodeis invoked to
fine the correct node to add the memory. This created the generic construct ofarch_find_node.
Quoted 8 lines
Quoted 3 lines
It would be cleaner to always call
add_memoryfrom architecture specific code instead of such ugly hooksHi, Keith
I don't like insert such a check (nid < 0) in
add_memory(), either. Could you add it before callingadd_memory()?
(for example,find_pxmparh in acpi's add memory code.)
Agree.
I think that arch_find_node() should be called in acpi_get_node().
For the time being, I would like to post folloing patch for 2.6.18 to fix returning -1 if _PXM is not defined.
Because, not only your case, but also there might be a case that hot add code will be executed with NUMA kernel on NON-NUMA box.
Then, arch_find_node() should be add before this line.
Thanks.
-----
drivers/acpi/numa.c | 4 ++++ 1 files changed, 4 insertions(+)
drivers/acpi/numa.c +4 -0
@@ -263,6 +263,10 @@ int acpi_get_node(acpi_handle *handle)if (pxm >=0 ) node =acpi_map_pxm_to_node (pxm); +/* _PXM might not be defined by firmware. */ +if (node <0 ) + node =0 ; +return node; }EXPORT_SYMBOL (acpi_get_node);
Signature · 1 line
Yasunori Goto