[PATCH 0/7] numa: incremental fixes to generic per cpu numa_*_id() series

[PATCH 0/7] numa: incremental fixes to generic per cpu numa_*_id() series

[Lee Schermerhorn]

The following 7 patches address review comments on the 'generic percpu
numa_*_id()" series currently in the -mm tree [28apr10 mmotm].

Valdis Kletnieks confirmed that this series fixes the i386 !NUMA slab
build breakage that he reported.

With these patches, I have built and tested on x86_64 and ia64 NUMA.   In
addition I built mm/slab.o for x86_64 !NUMA and an entire i386 tree with the
i386 config that Andrew sent out in response to Vlad's report re: i386 !NUMA
slab.o breakage.

It should be obvious from the 'Subject' and the patch descriptions, where
the patches go in the mmotm series.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

[PATCH 0/7] numa: incremental fixes to generic per cpu numa_*_id() series

[Lee Schermerhorn]

The following 7 patches address review comments on the 'generic percpu
numa_*_id()" series currently in the -mm tree [28apr10 mmotm].

Valdis Kletnieks confirmed that this series fixes the i386 !NUMA slab
build breakage that he reported.

With these patches, I have built and tested on x86_64 and ia64 NUMA.   In
addition I built mm/slab.o for x86_64 !NUMA and an entire i386 tree with the
i386 config that Andrew sent out in response to Vlad's report re: i386 !NUMA
slab.o breakage.

It should be obvious from the 'Subject' and the patch descriptions, where
the patches go in the mmotm series.

[PATCH 1/7] numa-add-generic-percpu-var-numa_node_id-implementation-fix1

[Lee Schermerhorn]

Incremental patch 1 to
numa-add-generic-percpu-var-numa_node_id-implementation.patch
in 28apri10 mmotm.

If any of the numa topology functions--numa_node_id() et al--have not
been overridden by the arch, we can define them as static inline
functions.

Note that this means that cpu_to_node() can no longer be used as an
lvalue.  However, the tree contains no such usage currently, and
a subsequent patch will add a function to set the 'numa_node' for
a specified cpu.

x86 defines numa_node_id() as a static inline function when
CONFIG_NUMA is not set.  Add #define of numa_node_id to itself
to indicate this override of the default definition, so we can
build !NUMA with this patch applied.

   Maybe we should move the default definitions to
   asm-generic/topology.h?  Or remove it altogether?
   x86_64 !NUMA seems to build without it.

Signed-off-by: Lee Schermerhorn <lee.schermerhorn@hp.com>

 arch/x86/include/asm/topology.h |    4 ++++
 include/linux/topology.h        |   21 ++++++++++++++++-----
 2 files changed, 20 insertions(+), 5 deletions(-)

Index: linux-2.6.34-rc5-mmotm-100428-1653/include/linux/topology.h
===================================================================
--- linux-2.6.34-rc5-mmotm-100428-1653.orig/include/linux/topology.h
+++ linux-2.6.34-rc5-mmotm-100428-1653/include/linux/topology.h
@@ -212,23 +212,34 @@ DECLARE_PER_CPU(int, numa_node);
 
 #ifndef numa_node_id
 /* Returns the number of the current Node. */
-#define numa_node_id()		__this_cpu_read(numa_node)
+static inline int numa_node_id(void)
+{
+	return __this_cpu_read(numa_node);
+}
 #endif
 
 #ifndef cpu_to_node
-#define cpu_to_node(__cpu)	per_cpu(numa_node, (__cpu))
+static inline int cpu_to_node(int cpu)
+{
+	return per_cpu(numa_node, cpu);
+}
 #endif
 
 #ifndef set_numa_node
-#define set_numa_node(__node) percpu_write(numa_node, __node)
+static inline void set_numa_node(int node)
+{
+	percpu_write(numa_node, node);
+}
 #endif
 
 #else	/* !CONFIG_USE_PERCPU_NUMA_NODE_ID */
 
 /* Returns the number of the current Node. */
 #ifndef numa_node_id
-#define numa_node_id()		(cpu_to_node(raw_smp_processor_id()))
-
+static inline int numa_node_id(void)
+{
+	return cpu_to_node(raw_smp_processor_id());
+}
 #endif
 
 #endif	/* [!]CONFIG_USE_PERCPU_NUMA_NODE_ID */
Index: linux-2.6.34-rc5-mmotm-100428-1653/arch/x86/include/asm/topology.h
===================================================================
--- linux-2.6.34-rc5-mmotm-100428-1653.orig/arch/x86/include/asm/topology.h
+++ linux-2.6.34-rc5-mmotm-100428-1653/arch/x86/include/asm/topology.h
@@ -170,6 +170,10 @@ static inline int numa_node_id(void)
 {
 	return 0;
 }
+/*
+ * indicate override:
+ */
+#define numa_node_id numa_node_id
 
 static inline int early_cpu_to_node(int cpu)
 {

[PATCH 1/7] numa-add-generic-percpu-var-numa_node_id-implementation-fix1

[Lee Schermerhorn]

Incremental patch 1 to
numa-add-generic-percpu-var-numa_node_id-implementation.patch
in 28apri10 mmotm.

If any of the numa topology functions--numa_node_id() et al--have not
been overridden by the arch, we can define them as static inline
functions.

Note that this means that cpu_to_node() can no longer be used as an
lvalue.  However, the tree contains no such usage currently, and
a subsequent patch will add a function to set the 'numa_node' for
a specified cpu.

x86 defines numa_node_id() as a static inline function when
CONFIG_NUMA is not set.  Add #define of numa_node_id to itself
to indicate this override of the default definition, so we can
build !NUMA with this patch applied.

   Maybe we should move the default definitions to
   asm-generic/topology.h?  Or remove it altogether?
   x86_64 !NUMA seems to build without it.

Signed-off-by: Lee Schermerhorn <lee.schermerhorn@hp.com>

 arch/x86/include/asm/topology.h |    4 ++++
 include/linux/topology.h        |   21 ++++++++++++++++-----
 2 files changed, 20 insertions(+), 5 deletions(-)

Index: linux-2.6.34-rc5-mmotm-100428-1653/include/linux/topology.h
===================================================================
--- linux-2.6.34-rc5-mmotm-100428-1653.orig/include/linux/topology.h
+++ linux-2.6.34-rc5-mmotm-100428-1653/include/linux/topology.h
@@ -212,23 +212,34 @@ DECLARE_PER_CPU(int, numa_node);
 
 #ifndef numa_node_id
 /* Returns the number of the current Node. */
-#define numa_node_id()		__this_cpu_read(numa_node)
+static inline int numa_node_id(void)
+{
+	return __this_cpu_read(numa_node);
+}
 #endif
 
 #ifndef cpu_to_node
-#define cpu_to_node(__cpu)	per_cpu(numa_node, (__cpu))
+static inline int cpu_to_node(int cpu)
+{
+	return per_cpu(numa_node, cpu);
+}
 #endif
 
 #ifndef set_numa_node
-#define set_numa_node(__node) percpu_write(numa_node, __node)
+static inline void set_numa_node(int node)
+{
+	percpu_write(numa_node, node);
+}
 #endif
 
 #else	/* !CONFIG_USE_PERCPU_NUMA_NODE_ID */
 
 /* Returns the number of the current Node. */
 #ifndef numa_node_id
-#define numa_node_id()		(cpu_to_node(raw_smp_processor_id()))
-
+static inline int numa_node_id(void)
+{
+	return cpu_to_node(raw_smp_processor_id());
+}
 #endif
 
 #endif	/* [!]CONFIG_USE_PERCPU_NUMA_NODE_ID */
Index: linux-2.6.34-rc5-mmotm-100428-1653/arch/x86/include/asm/topology.h
===================================================================
--- linux-2.6.34-rc5-mmotm-100428-1653.orig/arch/x86/include/asm/topology.h
+++ linux-2.6.34-rc5-mmotm-100428-1653/arch/x86/include/asm/topology.h
@@ -170,6 +170,10 @@ static inline int numa_node_id(void)
 {
 	return 0;
 }
+/*
+ * indicate override:
+ */
+#define numa_node_id numa_node_id
 
 static inline int early_cpu_to_node(int cpu)
 {

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

[PATCH 2/7] numa-add-generic-percpu-var-numa_node_id-implementation-fix2

[Lee Schermerhorn]

Incremental patch 2 to
numa-add-generic-percpu-var-numa_node_id-implementation.patch
in 28apr10 mmotm.

Define generic macro to set 'numa_node' for a specified cpu as
suggested by Christoph Lameter and seconded by Tejun Heo.

Signed-off-by: Lee Schermerhorn <lee.schermerhorn@hp.com>

 include/linux/topology.h |    7 +++++++
 1 file changed, 7 insertions(+)

Index: linux-2.6.34-rc5-mmotm-100428-1653/include/linux/topology.h
===================================================================
--- linux-2.6.34-rc5-mmotm-100428-1653.orig/include/linux/topology.h
+++ linux-2.6.34-rc5-mmotm-100428-1653/include/linux/topology.h
@@ -232,6 +232,13 @@ static inline void set_numa_node(int nod
 }
 #endif
 
+#ifndef set_cpu_numa_node
+static inline void set_cpu_numa_node(int cpu, int node)
+{
+	per_cpu(numa_node, cpu) = node;
+}
+#endif
+
 #else	/* !CONFIG_USE_PERCPU_NUMA_NODE_ID */
 
 /* Returns the number of the current Node. */

[PATCH 2/7] numa-add-generic-percpu-var-numa_node_id-implementation-fix2

[Lee Schermerhorn]

Incremental patch 2 to
numa-add-generic-percpu-var-numa_node_id-implementation.patch
in 28apr10 mmotm.

Define generic macro to set 'numa_node' for a specified cpu as
suggested by Christoph Lameter and seconded by Tejun Heo.

Signed-off-by: Lee Schermerhorn <lee.schermerhorn@hp.com>

 include/linux/topology.h |    7 +++++++
 1 file changed, 7 insertions(+)

Index: linux-2.6.34-rc5-mmotm-100428-1653/include/linux/topology.h
===================================================================
--- linux-2.6.34-rc5-mmotm-100428-1653.orig/include/linux/topology.h
+++ linux-2.6.34-rc5-mmotm-100428-1653/include/linux/topology.h
@@ -232,6 +232,13 @@ static inline void set_numa_node(int nod
 }
 #endif
 
+#ifndef set_cpu_numa_node
+static inline void set_cpu_numa_node(int cpu, int node)
+{
+	per_cpu(numa_node, cpu) = node;
+}
+#endif
+
 #else	/* !CONFIG_USE_PERCPU_NUMA_NODE_ID */
 
 /* Returns the number of the current Node. */

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

[PATCH 3/7] numa-x86_64-use-generic-percpu-var-numa_node_id-implementation-fix1

[Lee Schermerhorn]

Incremental patch 1 to
numa-x86_64-use-generic-percpu-var-numa_node_id-implementation.patch
in 28apr10 mmotm.

Use generic percpu numa_node variable only for x86_64.

x86_32 will require separate support.  Not sure it's worth it.

Signed-off-by: Lee Schermerhorn <lee.schermerhorn@hp.com>

 arch/x86/Kconfig |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Index: linux-2.6.34-rc5-mmotm-100428-1653/arch/x86/Kconfig
===================================================================
--- linux-2.6.34-rc5-mmotm-100428-1653.orig/arch/x86/Kconfig
+++ linux-2.6.34-rc5-mmotm-100428-1653/arch/x86/Kconfig
@@ -1720,7 +1720,7 @@ config HAVE_ARCH_EARLY_PFN_TO_NID
 	depends on NUMA
 
 config USE_PERCPU_NUMA_NODE_ID
-	def_bool y
+	def_bool X86_64
 	depends on NUMA
 
 menu "Power management and ACPI options"

[PATCH 3/7] numa-x86_64-use-generic-percpu-var-numa_node_id-implementation-fix1

[Lee Schermerhorn]

Incremental patch 1 to
numa-x86_64-use-generic-percpu-var-numa_node_id-implementation.patch
in 28apr10 mmotm.

Use generic percpu numa_node variable only for x86_64.

x86_32 will require separate support.  Not sure it's worth it.

Signed-off-by: Lee Schermerhorn <lee.schermerhorn@hp.com>

 arch/x86/Kconfig |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Index: linux-2.6.34-rc5-mmotm-100428-1653/arch/x86/Kconfig
===================================================================
--- linux-2.6.34-rc5-mmotm-100428-1653.orig/arch/x86/Kconfig
+++ linux-2.6.34-rc5-mmotm-100428-1653/arch/x86/Kconfig
@@ -1720,7 +1720,7 @@ config HAVE_ARCH_EARLY_PFN_TO_NID
 	depends on NUMA
 
 config USE_PERCPU_NUMA_NODE_ID
-	def_bool y
+	def_bool X86_64
 	depends on NUMA
 
 menu "Power management and ACPI options"

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

[PATCH 4/7] numa-x86_64-use-generic-percpu-var-numa_node_id-implementation-fix2

[Lee Schermerhorn]

Incremental patch 2 to
numa-x86_64-use-generic-percpu-var-numa_node_id-implementation.patch
in 28apr10 mmotm.

Use generic function to set numa_node for a specified cpu as
suggested by Christoph Lameter and seconded by Tejun Heo.

Signed-off-by: Lee Schermerhorn <lee.schermerhorn@hp.com>

 arch/x86/kernel/setup_percpu.c |    2 +-
 arch/x86/mm/numa_64.c          |    2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

Index: linux-2.6.34-rc5-mmotm-100428-1653/arch/x86/mm/numa_64.c
===================================================================
--- linux-2.6.34-rc5-mmotm-100428-1653.orig/arch/x86/mm/numa_64.c
+++ linux-2.6.34-rc5-mmotm-100428-1653/arch/x86/mm/numa_64.c
@@ -806,7 +806,7 @@ void __cpuinit numa_set_node(int cpu, in
 	per_cpu(x86_cpu_to_node_map, cpu) = node;
 
 	if (node != NUMA_NO_NODE)
-		per_cpu(numa_node, cpu) = node;
+		set_cpu_numa_node(cpu, node);
 }
 
 void __cpuinit numa_clear_node(int cpu)
Index: linux-2.6.34-rc5-mmotm-100428-1653/arch/x86/kernel/setup_percpu.c
===================================================================
--- linux-2.6.34-rc5-mmotm-100428-1653.orig/arch/x86/kernel/setup_percpu.c
+++ linux-2.6.34-rc5-mmotm-100428-1653/arch/x86/kernel/setup_percpu.c
@@ -268,7 +268,7 @@ void __init setup_per_cpu_areas(void)
 	 * make sure boot cpu numa_node is right, when boot cpu is on the
 	 * node that doesn't have mem installed
 	 */
-	per_cpu(numa_node, boot_cpu_id) = early_cpu_to_node(boot_cpu_id);
+	set_cpu_numa_node(boot_cpu_id, early_cpu_to_node(boot_cpu_id));
 #endif
 
 	/* Setup node to cpumask map */

[PATCH 4/7] numa-x86_64-use-generic-percpu-var-numa_node_id-implementation-fix2

[Lee Schermerhorn]

Incremental patch 2 to
numa-x86_64-use-generic-percpu-var-numa_node_id-implementation.patch
in 28apr10 mmotm.

Use generic function to set numa_node for a specified cpu as
suggested by Christoph Lameter and seconded by Tejun Heo.

Signed-off-by: Lee Schermerhorn <lee.schermerhorn@hp.com>

 arch/x86/kernel/setup_percpu.c |    2 +-
 arch/x86/mm/numa_64.c          |    2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

Index: linux-2.6.34-rc5-mmotm-100428-1653/arch/x86/mm/numa_64.c
===================================================================
--- linux-2.6.34-rc5-mmotm-100428-1653.orig/arch/x86/mm/numa_64.c
+++ linux-2.6.34-rc5-mmotm-100428-1653/arch/x86/mm/numa_64.c
@@ -806,7 +806,7 @@ void __cpuinit numa_set_node(int cpu, in
 	per_cpu(x86_cpu_to_node_map, cpu) = node;
 
 	if (node != NUMA_NO_NODE)
-		per_cpu(numa_node, cpu) = node;
+		set_cpu_numa_node(cpu, node);
 }
 
 void __cpuinit numa_clear_node(int cpu)
Index: linux-2.6.34-rc5-mmotm-100428-1653/arch/x86/kernel/setup_percpu.c
===================================================================
--- linux-2.6.34-rc5-mmotm-100428-1653.orig/arch/x86/kernel/setup_percpu.c
+++ linux-2.6.34-rc5-mmotm-100428-1653/arch/x86/kernel/setup_percpu.c
@@ -268,7 +268,7 @@ void __init setup_per_cpu_areas(void)
 	 * make sure boot cpu numa_node is right, when boot cpu is on the
 	 * node that doesn't have mem installed
 	 */
-	per_cpu(numa_node, boot_cpu_id) = early_cpu_to_node(boot_cpu_id);
+	set_cpu_numa_node(boot_cpu_id, early_cpu_to_node(boot_cpu_id));
 #endif
 
 	/* Setup node to cpumask map */

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

[PATCH 5/7] numa-introduce-numa_mem_id-effective-local-memory-node-id-fix2

[Lee Schermerhorn]

Incremental patch 1 to
numa-introduce-numa_mem_id-effective-local-memory-node-id.patch
in mmotm 100428-1638.  Atop Andrew's build fix to that patch.

If any of the numa topology functions--numa_mem_id() et al--have not
been overridden by the arch, we can define them as static inline
functions.

Now, since we can no longer use cpu_to_mem() as an lvalue, also
define set_cpu_numa_mem(cpu, node) and use this to initialize the
per cpu numa_mem variable in __build_all_zonelists().

Signed-off-by: Lee Schermerhorn <lee.schermerhorn@hp.com>

 include/linux/topology.h |   24 +++++++++++++++++++++---
 mm/page_alloc.c          |    2 +-
 2 files changed, 22 insertions(+), 4 deletions(-)

Index: linux-2.6.34-rc5-mmotm-100428-1653/include/linux/topology.h
===================================================================
--- linux-2.6.34-rc5-mmotm-100428-1653.orig/include/linux/topology.h
+++ linux-2.6.34-rc5-mmotm-100428-1653/include/linux/topology.h
@@ -256,7 +256,17 @@ static inline int numa_node_id(void)
 DECLARE_PER_CPU(int, numa_mem);
 
 #ifndef set_numa_mem
-#define set_numa_mem(__node) percpu_write(numa_mem, __node)
+static inline void set_numa_mem(int node)
+{
+	percpu_write(numa_mem, node);
+}
+#endif
+
+#ifndef set_cpu_numa_mem
+static inline void set_cpu_numa_mem(int cpu, int node)
+{
+	per_cpu(numa_mem, cpu) = node;
+}
 #endif
 
 #else	/* !CONFIG_HAVE_MEMORYLESS_NODES */
@@ -264,15 +274,23 @@ DECLARE_PER_CPU(int, numa_mem);
 #define numa_mem numa_node
 static inline void set_numa_mem(int node) {}
 
+static inline void set_cpu_numa_mem(int cpu, int node) {}
+
 #endif	/* [!]CONFIG_HAVE_MEMORYLESS_NODES */
 
 #ifndef numa_mem_id
 /* Returns the number of the nearest Node with memory */
-#define numa_mem_id()		__this_cpu_read(numa_mem)
+static inline int numa_mem_id(void)
+{
+	return __this_cpu_read(numa_mem);
+}
 #endif
 
 #ifndef cpu_to_mem
-#define cpu_to_mem(__cpu)	per_cpu(numa_mem, (__cpu))
+static inline int cpu_to_mem(int cpu)
+{
+	return per_cpu(numa_mem, cpu);
+}
 #endif
 
 #ifndef topology_physical_package_id
Index: linux-2.6.34-rc5-mmotm-100428-1653/mm/page_alloc.c
===================================================================
--- linux-2.6.34-rc5-mmotm-100428-1653.orig/mm/page_alloc.c
+++ linux-2.6.34-rc5-mmotm-100428-1653/mm/page_alloc.c
@@ -3000,7 +3000,7 @@ static int __build_all_zonelists(void *d
 		 * node/memory hotplug, we'll fixup all on-line cpus.
 		 */
 		if (cpu_online(cpu))
-			cpu_to_mem(cpu) = local_memory_node(cpu_to_node(cpu));
+			set_cpu_numa_mem(cpu, local_memory_node(cpu_to_node(cpu)));
 #endif
 	}
 

[PATCH 5/7] numa-introduce-numa_mem_id-effective-local-memory-node-id-fix2

[Lee Schermerhorn]

Incremental patch 1 to
numa-introduce-numa_mem_id-effective-local-memory-node-id.patch
in mmotm 100428-1638.  Atop Andrew's build fix to that patch.

If any of the numa topology functions--numa_mem_id() et al--have not
been overridden by the arch, we can define them as static inline
functions.

Now, since we can no longer use cpu_to_mem() as an lvalue, also
define set_cpu_numa_mem(cpu, node) and use this to initialize the
per cpu numa_mem variable in __build_all_zonelists().

Signed-off-by: Lee Schermerhorn <lee.schermerhorn@hp.com>

 include/linux/topology.h |   24 +++++++++++++++++++++---
 mm/page_alloc.c          |    2 +-
 2 files changed, 22 insertions(+), 4 deletions(-)

Index: linux-2.6.34-rc5-mmotm-100428-1653/include/linux/topology.h
===================================================================
--- linux-2.6.34-rc5-mmotm-100428-1653.orig/include/linux/topology.h
+++ linux-2.6.34-rc5-mmotm-100428-1653/include/linux/topology.h
@@ -256,7 +256,17 @@ static inline int numa_node_id(void)
 DECLARE_PER_CPU(int, numa_mem);
 
 #ifndef set_numa_mem
-#define set_numa_mem(__node) percpu_write(numa_mem, __node)
+static inline void set_numa_mem(int node)
+{
+	percpu_write(numa_mem, node);
+}
+#endif
+
+#ifndef set_cpu_numa_mem
+static inline void set_cpu_numa_mem(int cpu, int node)
+{
+	per_cpu(numa_mem, cpu) = node;
+}
 #endif
 
 #else	/* !CONFIG_HAVE_MEMORYLESS_NODES */
@@ -264,15 +274,23 @@ DECLARE_PER_CPU(int, numa_mem);
 #define numa_mem numa_node
 static inline void set_numa_mem(int node) {}
 
+static inline void set_cpu_numa_mem(int cpu, int node) {}
+
 #endif	/* [!]CONFIG_HAVE_MEMORYLESS_NODES */
 
 #ifndef numa_mem_id
 /* Returns the number of the nearest Node with memory */
-#define numa_mem_id()		__this_cpu_read(numa_mem)
+static inline int numa_mem_id(void)
+{
+	return __this_cpu_read(numa_mem);
+}
 #endif
 
 #ifndef cpu_to_mem
-#define cpu_to_mem(__cpu)	per_cpu(numa_mem, (__cpu))
+static inline int cpu_to_mem(int cpu)
+{
+	return per_cpu(numa_mem, cpu);
+}
 #endif
 
 #ifndef topology_physical_package_id
Index: linux-2.6.34-rc5-mmotm-100428-1653/mm/page_alloc.c
===================================================================
--- linux-2.6.34-rc5-mmotm-100428-1653.orig/mm/page_alloc.c
+++ linux-2.6.34-rc5-mmotm-100428-1653/mm/page_alloc.c
@@ -3000,7 +3000,7 @@ static int __build_all_zonelists(void *d
 		 * node/memory hotplug, we'll fixup all on-line cpus.
 		 */
 		if (cpu_online(cpu))
-			cpu_to_mem(cpu) = local_memory_node(cpu_to_node(cpu));
+			set_cpu_numa_mem(cpu, local_memory_node(cpu_to_node(cpu)));
 #endif
 	}
 

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

[PATCH 6/7] numa-introduce-numa_mem_id-effective-local-memory-node-id-fix3

[Lee Schermerhorn]

Incremental patch 2 to
numa-introduce-numa_mem_id-effective-local-memory-node-id
in 28april10 mmotm.

Remove the "#define numa_mem numa_node" when !HAVE_MEMORYLESS_NODES
from topology.h per Tejun Heo.  Because 'numa_mem' is [was] a percpu
variable, we cannot make it a macro with arguments or a static inline
function.  I considered making it a variable alias for numa_node, but
since both are percpu variables whose actual definitions and declarations
are buried deep in the DECLARE_PER_CPU() macros, I proposed a
DECLARE_PER_CPU_ALIAS(variable, alias).  Tejun agreed that if this
were a common occurrence, that would be a good idea, but since we
currently have only this instance, we agreed to just eliminate
the numa_mem variable when !HAVE_MEMORYLESS_NODES.

This patch renames the variable to _numa_mem_ and adds warnings
in both linux/topology.h and mm/page_alloc.c against referencing
the variable directly.  The accessor functions numa_mem_id() and
cpu_to_mem() will return the appropriate value when
!HAVE_MEMORYLESS_NODES.

Signed-off-by: Lee Schermerhorn <lee.schermerhorn@hp.com>

 include/linux/topology.h |   35 +++++++++++++++++++++++++++--------
 mm/page_alloc.c          |   10 ++++++++--
 2 files changed, 35 insertions(+), 10 deletions(-)

Index: linux-2.6.34-rc5-mmotm-100428-1653/include/linux/topology.h
===================================================================
--- linux-2.6.34-rc5-mmotm-100428-1653.orig/include/linux/topology.h
+++ linux-2.6.34-rc5-mmotm-100428-1653/include/linux/topology.h
@@ -253,46 +253,65 @@ static inline int numa_node_id(void)
 
 #ifdef CONFIG_HAVE_MEMORYLESS_NODES
 
-DECLARE_PER_CPU(int, numa_mem);
+/*
+ * N.B., Do NOT reference the '_numa_mem_' per cpu variable directly.
+ * It will not be defined when CONFIG_HAVE_MEMORYLESS_NODES is not defined.
+ * Use the accessor functions set_numa_mem(), numa_mem_id() and cpu_to_mem().
+ */
+DECLARE_PER_CPU(int, _numa_mem_);
 
 #ifndef set_numa_mem
 static inline void set_numa_mem(int node)
 {
-	percpu_write(numa_mem, node);
+	percpu_write(_numa_mem_, node);
+}
+#endif
+
+#ifndef numa_mem_id
+/* Returns the number of the nearest Node with memory */
+static inline int numa_mem_id(void)
+{
+	return __this_cpu_read(_numa_mem_);
+}
+#endif
+
+#ifndef cpu_to_mem
+static inline int cpu_to_mem(int cpu)
+{
+	return per_cpu(_numa_mem_, cpu);
 }
 #endif
 
 #ifndef set_cpu_numa_mem
 static inline void set_cpu_numa_mem(int cpu, int node)
 {
-	per_cpu(numa_mem, cpu) = node;
+	per_cpu(_numa_mem_, cpu) = node;
 }
 #endif
 
 #else	/* !CONFIG_HAVE_MEMORYLESS_NODES */
 
-#define numa_mem numa_node
 static inline void set_numa_mem(int node) {}
 
 static inline void set_cpu_numa_mem(int cpu, int node) {}
 
-#endif	/* [!]CONFIG_HAVE_MEMORYLESS_NODES */
-
 #ifndef numa_mem_id
 /* Returns the number of the nearest Node with memory */
 static inline int numa_mem_id(void)
 {
-	return __this_cpu_read(numa_mem);
+	return numa_node_id();
 }
 #endif
 
 #ifndef cpu_to_mem
 static inline int cpu_to_mem(int cpu)
 {
-	return per_cpu(numa_mem, cpu);
+	return cpu_to_node(cpu);
 }
 #endif
 
+#endif	/* [!]CONFIG_HAVE_MEMORYLESS_NODES */
+
 #ifndef topology_physical_package_id
 #define topology_physical_package_id(cpu)	((void)(cpu), -1)
 #endif
Index: linux-2.6.34-rc5-mmotm-100428-1653/mm/page_alloc.c
===================================================================
--- linux-2.6.34-rc5-mmotm-100428-1653.orig/mm/page_alloc.c
+++ linux-2.6.34-rc5-mmotm-100428-1653/mm/page_alloc.c
@@ -63,8 +63,14 @@ EXPORT_PER_CPU_SYMBOL(numa_node);
 #endif
 
 #ifdef CONFIG_HAVE_MEMORYLESS_NODES
-DEFINE_PER_CPU(int, numa_mem);		/* Kernel "local memory" node */
-EXPORT_PER_CPU_SYMBOL(numa_mem);
+/*
+ * N.B., Do NOT reference the '_numa_mem_' per cpu variable directly.
+ * It will not be defined when CONFIG_HAVE_MEMORYLESS_NODES is not defined.
+ * Use the accessor functions set_numa_mem(), numa_mem_id() and cpu_to_mem()
+ * defined in <linux/topology.h>.
+ */
+DEFINE_PER_CPU(int, _numa_mem_);		/* Kernel "local memory" node */
+EXPORT_PER_CPU_SYMBOL(_numa_mem_);
 #endif
 
 /*

[PATCH 6/7] numa-introduce-numa_mem_id-effective-local-memory-node-id-fix3

[Lee Schermerhorn]

Incremental patch 2 to
numa-introduce-numa_mem_id-effective-local-memory-node-id
in 28april10 mmotm.

Remove the "#define numa_mem numa_node" when !HAVE_MEMORYLESS_NODES
from topology.h per Tejun Heo.  Because 'numa_mem' is [was] a percpu
variable, we cannot make it a macro with arguments or a static inline
function.  I considered making it a variable alias for numa_node, but
since both are percpu variables whose actual definitions and declarations
are buried deep in the DECLARE_PER_CPU() macros, I proposed a
DECLARE_PER_CPU_ALIAS(variable, alias).  Tejun agreed that if this
were a common occurrence, that would be a good idea, but since we
currently have only this instance, we agreed to just eliminate
the numa_mem variable when !HAVE_MEMORYLESS_NODES.

This patch renames the variable to _numa_mem_ and adds warnings
in both linux/topology.h and mm/page_alloc.c against referencing
the variable directly.  The accessor functions numa_mem_id() and
cpu_to_mem() will return the appropriate value when
!HAVE_MEMORYLESS_NODES.

Signed-off-by: Lee Schermerhorn <lee.schermerhorn@hp.com>

 include/linux/topology.h |   35 +++++++++++++++++++++++++++--------
 mm/page_alloc.c          |   10 ++++++++--
 2 files changed, 35 insertions(+), 10 deletions(-)

Index: linux-2.6.34-rc5-mmotm-100428-1653/include/linux/topology.h
===================================================================
--- linux-2.6.34-rc5-mmotm-100428-1653.orig/include/linux/topology.h
+++ linux-2.6.34-rc5-mmotm-100428-1653/include/linux/topology.h
@@ -253,46 +253,65 @@ static inline int numa_node_id(void)
 
 #ifdef CONFIG_HAVE_MEMORYLESS_NODES
 
-DECLARE_PER_CPU(int, numa_mem);
+/*
+ * N.B., Do NOT reference the '_numa_mem_' per cpu variable directly.
+ * It will not be defined when CONFIG_HAVE_MEMORYLESS_NODES is not defined.
+ * Use the accessor functions set_numa_mem(), numa_mem_id() and cpu_to_mem().
+ */
+DECLARE_PER_CPU(int, _numa_mem_);
 
 #ifndef set_numa_mem
 static inline void set_numa_mem(int node)
 {
-	percpu_write(numa_mem, node);
+	percpu_write(_numa_mem_, node);
+}
+#endif
+
+#ifndef numa_mem_id
+/* Returns the number of the nearest Node with memory */
+static inline int numa_mem_id(void)
+{
+	return __this_cpu_read(_numa_mem_);
+}
+#endif
+
+#ifndef cpu_to_mem
+static inline int cpu_to_mem(int cpu)
+{
+	return per_cpu(_numa_mem_, cpu);
 }
 #endif
 
 #ifndef set_cpu_numa_mem
 static inline void set_cpu_numa_mem(int cpu, int node)
 {
-	per_cpu(numa_mem, cpu) = node;
+	per_cpu(_numa_mem_, cpu) = node;
 }
 #endif
 
 #else	/* !CONFIG_HAVE_MEMORYLESS_NODES */
 
-#define numa_mem numa_node
 static inline void set_numa_mem(int node) {}
 
 static inline void set_cpu_numa_mem(int cpu, int node) {}
 
-#endif	/* [!]CONFIG_HAVE_MEMORYLESS_NODES */
-
 #ifndef numa_mem_id
 /* Returns the number of the nearest Node with memory */
 static inline int numa_mem_id(void)
 {
-	return __this_cpu_read(numa_mem);
+	return numa_node_id();
 }
 #endif
 
 #ifndef cpu_to_mem
 static inline int cpu_to_mem(int cpu)
 {
-	return per_cpu(numa_mem, cpu);
+	return cpu_to_node(cpu);
 }
 #endif
 
+#endif	/* [!]CONFIG_HAVE_MEMORYLESS_NODES */
+
 #ifndef topology_physical_package_id
 #define topology_physical_package_id(cpu)	((void)(cpu), -1)
 #endif
Index: linux-2.6.34-rc5-mmotm-100428-1653/mm/page_alloc.c
===================================================================
--- linux-2.6.34-rc5-mmotm-100428-1653.orig/mm/page_alloc.c
+++ linux-2.6.34-rc5-mmotm-100428-1653/mm/page_alloc.c
@@ -63,8 +63,14 @@ EXPORT_PER_CPU_SYMBOL(numa_node);
 #endif
 
 #ifdef CONFIG_HAVE_MEMORYLESS_NODES
-DEFINE_PER_CPU(int, numa_mem);		/* Kernel "local memory" node */
-EXPORT_PER_CPU_SYMBOL(numa_mem);
+/*
+ * N.B., Do NOT reference the '_numa_mem_' per cpu variable directly.
+ * It will not be defined when CONFIG_HAVE_MEMORYLESS_NODES is not defined.
+ * Use the accessor functions set_numa_mem(), numa_mem_id() and cpu_to_mem()
+ * defined in <linux/topology.h>.
+ */
+DEFINE_PER_CPU(int, _numa_mem_);		/* Kernel "local memory" node */
+EXPORT_PER_CPU_SYMBOL(_numa_mem_);
 #endif
 
 /*

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

[PATCH 7/7] numa-update-documentation-vm-numa-add-memoryless-node-info-fix1

[Lee Schermerhorn]

Incremental patch to
numa-update-documentation-vm-numa-add-memoryless-node-info.patch
in 28april'10 mmotm.

Address Randy Dunlap's review comments plus a few other fixups.

Signed-off-by: Lee Schermerhorn <lee.schermerhorn@hp.com>

 Documentation/vm/numa |   58 +++++++++++++++++++++++++-------------------------
 1 file changed, 29 insertions(+), 29 deletions(-)

Index: linux-2.6.34-rc5-mmotm-100428-1653/Documentation/vm/numa
===================================================================
--- linux-2.6.34-rc5-mmotm-100428-1653.orig/Documentation/vm/numa
+++ linux-2.6.34-rc5-mmotm-100428-1653/Documentation/vm/numa
@@ -7,7 +7,7 @@ hardware view and the Linux software vie
 
 From the hardware perspective, a NUMA system is a computer platform that
 comprises multiple components or assemblies each of which may contain 0
-or more cpus, local memory, and/or IO buses.  For brevity and to
+or more CPUs, local memory, and/or IO buses.  For brevity and to
 disambiguate the hardware view of these physical components/assemblies
 from the software abstraction thereof, we'll call the components/assemblies
 'cells' in this document.
@@ -21,13 +21,13 @@ these types of interconnects can be aggr
 cells at multiple distances from other cells.
 
 For Linux, the NUMA platforms of interest are primarily what is known as Cache
-Coherent NUMA or CCNuma systems.   With CCNUMA systems, all memory is visible
-to and accessible from any cpu attached to any cell and cache coherency
+Coherent NUMA or ccNUMA systems.   With ccNUMA systems, all memory is visible
+to and accessible from any CPU attached to any cell and cache coherency
 is handled in hardware by the processor caches and/or the system interconnect.
 
 Memory access time and effective memory bandwidth varies depending on how far
-away the cell containing the cpu or io bus making the memory access is from the
-cell containing the target memory.  For example, access to memory by cpus
+away the cell containing the CPU or IO bus making the memory access is from the
+cell containing the target memory.  For example, access to memory by CPUs
 attached to the same cell will experience faster access times and higher
 bandwidths than accesses to memory on other, remote cells.  NUMA platforms
 can have cells at multiple remote distances from any given cell.
@@ -45,25 +45,25 @@ Linux divides the system's hardware reso
 abstractions called "nodes".  Linux maps the nodes onto the physical cells
 of the hardware platform, abstracting away some of the details for some
 architectures.  As with physical cells, software nodes may contain 0 or more
-cpus, memory and/or IO buses.  And, again, memory access times to memory on
-"closer" nodes [nodes that map to closer cells] will generally experience
+CPUs, memory and/or IO buses.  And, again, memory accesses to memory on
+"closer" nodes--nodes that map to closer cells--will generally experience
 faster access times and higher effective bandwidth than accesses to more
 remote cells.
 
 For some architectures, such as x86, Linux will "hide" any node representing a
-physical cell that has no memory attached, and reassign any cpus attached to
+physical cell that has no memory attached, and reassign any CPUs attached to
 that cell to a node representing a cell that does have memory.  Thus, on
-these architectures, one cannot assume that all cpus that Linux associates with
+these architectures, one cannot assume that all CPUs that Linux associates with
 a given node will see the same local memory access times and bandwidth.
 
 In addition, for some architectures, again x86 is an example, Linux supports
 the emulation of additional nodes.  For NUMA emulation, linux will carve up
 the existing nodes--or the system memory for non-NUMA platforms--into multiple
 nodes.  Each emulated node will manage a fraction of the underlying cells'
-physical memory.  Numa emluation is useful for testing NUMA kernel and
+physical memory.  NUMA emluation is useful for testing NUMA kernel and
 application features on non-NUMA platforms, and as a sort of memory resource
 management mechanism when used together with cpusets.
-[See Documentation/cgroups/cpusets.txt]
+[see Documentation/cgroups/cpusets.txt]
 
 For each node with memory, Linux constructs an independent memory management
 subsystem, complete with its own free page lists, in-use page lists, usage
@@ -71,8 +71,8 @@ statistics and locks to mediate access.
 each memory zone [one or more of DMA, DMA32, NORMAL, HIGH_MEMORY, MOVABLE],
 an ordered "zonelist".  A zonelist specifies the zones/nodes to visit when a
 selected zone/node cannot satisfy the allocation request.  This situation,
-when a zone's has no available memory to satisfy a request, is called
-'overflow" or "fallback".
+when a zone has no available memory to satisfy a request, is called
+"overflow" or "fallback".
 
 Because some nodes contain multiple zones containing different types of
 memory, Linux must decide whether to order the zonelists such that allocations
@@ -82,11 +82,11 @@ such as DMA or DMA32, represent relative
 a default zonelist order based on the sizes of the various zone types relative
 to the total memory of the node and the total memory of the system.  The
 default zonelist order may be overridden using the numa_zonelist_order kernel
-boot parameter or sysctl.  [See Documentation/kernel-parameters.txt and
+boot parameter or sysctl.  [see Documentation/kernel-parameters.txt and
 Documentation/sysctl/vm.txt]
 
 By default, Linux will attempt to satisfy memory allocation requests from the
-node to which the cpu that executes the request is assigned.  Specifically,
+node to which the CPU that executes the request is assigned.  Specifically,
 Linux will attempt to allocate from the first node in the appropriate zonelist
 for the node where the request originates.  This is called "local allocation."
 If the "local" node cannot satisfy the request, the kernel will examine other
@@ -98,26 +98,26 @@ Local allocation will tend to keep subse
 as long as the task on whose behalf the kernel allocated some memory does not
 later migrate away from that memory.  The Linux scheduler is aware of the
 NUMA topology of the platform--embodied in the "scheduling domains" data
-structures [See Documentation/scheduler/sched-domains.txt]--and the scheduler
+structures [see Documentation/scheduler/sched-domains.txt]--and the scheduler
 attempts to minimize task migration to distant scheduling domains.  However,
 the scheduler does not take a task's NUMA footprint into account directly.
 Thus, under sufficient imbalance, tasks can migrate between nodes, remote
 from their initial node and kernel data structures.
 
-System administrators and application designers can restrict a tasks migration
-to improve NUMA locality using various cpu affinity command line interfaces,
+System administrators and application designers can restrict a task's migration
+to improve NUMA locality using various CPU affinity command line interfaces,
 such as taskset(1) and numactl(1), and program interfaces such as
 sched_setaffinity(2).  Further, one can modify the kernel's default local
 allocation behavior using Linux NUMA memory policy.
-[See Documentation/vm/numa_memory_policy.]
+[see Documentation/vm/numa_memory_policy.]
 
-System administrators can restrict the cpus and nodes' memories that a non-
+System administrators can restrict the CPUs and nodes' memories that a non-
 privileged user can specify in the scheduling or NUMA commands and functions
-using control groups and cpusets.  [See Documentation/cgroups/cpusets.txt]
+using control groups and CPUsets.  [see Documentation/cgroups/CPUsets.txt]
 
 On architectures that do not hide memoryless nodes, Linux will include only
 zones [nodes] with memory in the zonelists.  This means that for a memoryless
-node the "local memory node"--the node of the first zone in cpu's node's
+node the "local memory node"--the node of the first zone in CPU's node's
 zonelist--will not be the node itself.  Rather, it will be the node that the
 kernel selected as the nearest node with memory when it built the zonelists.
 So, default, local allocations will succeed with the kernel supplying the
@@ -128,22 +128,22 @@ does contain memory overflows.
 Some kernel allocations do not want or cannot tolerate this allocation fallback
 behavior.  Rather they want to be sure they get memory from the specified node
 or get notified that the node has no free memory.  This is usually the case when
-a subsystem allocates per cpu memory resources, for example.
+a subsystem allocates per CPU memory resources, for example.
 
 A typical model for making such an allocation is to obtain the node id of the
-node to which the "current cpu" is attached using one of the kernel's
-numa_node_id() or cpu_to_node() functions and then request memory from only
+node to which the "current CPU" is attached using one of the kernel's
+numa_node_id() or CPU_to_node() functions and then request memory from only
 the node id returned.  When such an allocation fails, the requesting subsystem
 may revert to its own fallback path.  The slab kernel memory allocator is an
-example of this.  Or, the subsystem may chose to disable or not to enable
+example of this.  Or, the subsystem may choose to disable or not to enable
 itself on allocation failure.  The kernel profiling subsystem is an example of
 this.
 
-If the architecture supports [does not hide] memoryless nodes, then cpus
+If the architecture supports--does not hide--memoryless nodes, then CPUs
 attached to memoryless nodes would always incur the fallback path overhead
 or some subsystems would fail to initialize if they attempted to allocated
-memory exclusively from the a node without memory.  To support such
+memory exclusively from a node without memory.  To support such
 architectures transparently, kernel subsystems can use the numa_mem_id()
 or cpu_to_mem() function to locate the "local memory node" for the calling or
-specified cpu.  Again, this is the same node from which default, local page
+specified CPU.  Again, this is the same node from which default, local page
 allocations will be attempted.

[PATCH 7/7] numa-update-documentation-vm-numa-add-memoryless-node-info-fix1

[Lee Schermerhorn]

Incremental patch to
numa-update-documentation-vm-numa-add-memoryless-node-info.patch
in 28april'10 mmotm.

Address Randy Dunlap's review comments plus a few other fixups.

Signed-off-by: Lee Schermerhorn <lee.schermerhorn@hp.com>

 Documentation/vm/numa |   58 +++++++++++++++++++++++++-------------------------
 1 file changed, 29 insertions(+), 29 deletions(-)

Index: linux-2.6.34-rc5-mmotm-100428-1653/Documentation/vm/numa
===================================================================
--- linux-2.6.34-rc5-mmotm-100428-1653.orig/Documentation/vm/numa
+++ linux-2.6.34-rc5-mmotm-100428-1653/Documentation/vm/numa
@@ -7,7 +7,7 @@ hardware view and the Linux software vie
 
 From the hardware perspective, a NUMA system is a computer platform that
 comprises multiple components or assemblies each of which may contain 0
-or more cpus, local memory, and/or IO buses.  For brevity and to
+or more CPUs, local memory, and/or IO buses.  For brevity and to
 disambiguate the hardware view of these physical components/assemblies
 from the software abstraction thereof, we'll call the components/assemblies
 'cells' in this document.
@@ -21,13 +21,13 @@ these types of interconnects can be aggr
 cells at multiple distances from other cells.
 
 For Linux, the NUMA platforms of interest are primarily what is known as Cache
-Coherent NUMA or CCNuma systems.   With CCNUMA systems, all memory is visible
-to and accessible from any cpu attached to any cell and cache coherency
+Coherent NUMA or ccNUMA systems.   With ccNUMA systems, all memory is visible
+to and accessible from any CPU attached to any cell and cache coherency
 is handled in hardware by the processor caches and/or the system interconnect.
 
 Memory access time and effective memory bandwidth varies depending on how far
-away the cell containing the cpu or io bus making the memory access is from the
-cell containing the target memory.  For example, access to memory by cpus
+away the cell containing the CPU or IO bus making the memory access is from the
+cell containing the target memory.  For example, access to memory by CPUs
 attached to the same cell will experience faster access times and higher
 bandwidths than accesses to memory on other, remote cells.  NUMA platforms
 can have cells at multiple remote distances from any given cell.
@@ -45,25 +45,25 @@ Linux divides the system's hardware reso
 abstractions called "nodes".  Linux maps the nodes onto the physical cells
 of the hardware platform, abstracting away some of the details for some
 architectures.  As with physical cells, software nodes may contain 0 or more
-cpus, memory and/or IO buses.  And, again, memory access times to memory on
-"closer" nodes [nodes that map to closer cells] will generally experience
+CPUs, memory and/or IO buses.  And, again, memory accesses to memory on
+"closer" nodes--nodes that map to closer cells--will generally experience
 faster access times and higher effective bandwidth than accesses to more
 remote cells.
 
 For some architectures, such as x86, Linux will "hide" any node representing a
-physical cell that has no memory attached, and reassign any cpus attached to
+physical cell that has no memory attached, and reassign any CPUs attached to
 that cell to a node representing a cell that does have memory.  Thus, on
-these architectures, one cannot assume that all cpus that Linux associates with
+these architectures, one cannot assume that all CPUs that Linux associates with
 a given node will see the same local memory access times and bandwidth.
 
 In addition, for some architectures, again x86 is an example, Linux supports
 the emulation of additional nodes.  For NUMA emulation, linux will carve up
 the existing nodes--or the system memory for non-NUMA platforms--into multiple
 nodes.  Each emulated node will manage a fraction of the underlying cells'
-physical memory.  Numa emluation is useful for testing NUMA kernel and
+physical memory.  NUMA emluation is useful for testing NUMA kernel and
 application features on non-NUMA platforms, and as a sort of memory resource
 management mechanism when used together with cpusets.
-[See Documentation/cgroups/cpusets.txt]
+[see Documentation/cgroups/cpusets.txt]
 
 For each node with memory, Linux constructs an independent memory management
 subsystem, complete with its own free page lists, in-use page lists, usage
@@ -71,8 +71,8 @@ statistics and locks to mediate access.
 each memory zone [one or more of DMA, DMA32, NORMAL, HIGH_MEMORY, MOVABLE],
 an ordered "zonelist".  A zonelist specifies the zones/nodes to visit when a
 selected zone/node cannot satisfy the allocation request.  This situation,
-when a zone's has no available memory to satisfy a request, is called
-'overflow" or "fallback".
+when a zone has no available memory to satisfy a request, is called
+"overflow" or "fallback".
 
 Because some nodes contain multiple zones containing different types of
 memory, Linux must decide whether to order the zonelists such that allocations
@@ -82,11 +82,11 @@ such as DMA or DMA32, represent relative
 a default zonelist order based on the sizes of the various zone types relative
 to the total memory of the node and the total memory of the system.  The
 default zonelist order may be overridden using the numa_zonelist_order kernel
-boot parameter or sysctl.  [See Documentation/kernel-parameters.txt and
+boot parameter or sysctl.  [see Documentation/kernel-parameters.txt and
 Documentation/sysctl/vm.txt]
 
 By default, Linux will attempt to satisfy memory allocation requests from the
-node to which the cpu that executes the request is assigned.  Specifically,
+node to which the CPU that executes the request is assigned.  Specifically,
 Linux will attempt to allocate from the first node in the appropriate zonelist
 for the node where the request originates.  This is called "local allocation."
 If the "local" node cannot satisfy the request, the kernel will examine other
@@ -98,26 +98,26 @@ Local allocation will tend to keep subse
 as long as the task on whose behalf the kernel allocated some memory does not
 later migrate away from that memory.  The Linux scheduler is aware of the
 NUMA topology of the platform--embodied in the "scheduling domains" data
-structures [See Documentation/scheduler/sched-domains.txt]--and the scheduler
+structures [see Documentation/scheduler/sched-domains.txt]--and the scheduler
 attempts to minimize task migration to distant scheduling domains.  However,
 the scheduler does not take a task's NUMA footprint into account directly.
 Thus, under sufficient imbalance, tasks can migrate between nodes, remote
 from their initial node and kernel data structures.
 
-System administrators and application designers can restrict a tasks migration
-to improve NUMA locality using various cpu affinity command line interfaces,
+System administrators and application designers can restrict a task's migration
+to improve NUMA locality using various CPU affinity command line interfaces,
 such as taskset(1) and numactl(1), and program interfaces such as
 sched_setaffinity(2).  Further, one can modify the kernel's default local
 allocation behavior using Linux NUMA memory policy.
-[See Documentation/vm/numa_memory_policy.]
+[see Documentation/vm/numa_memory_policy.]
 
-System administrators can restrict the cpus and nodes' memories that a non-
+System administrators can restrict the CPUs and nodes' memories that a non-
 privileged user can specify in the scheduling or NUMA commands and functions
-using control groups and cpusets.  [See Documentation/cgroups/cpusets.txt]
+using control groups and CPUsets.  [see Documentation/cgroups/CPUsets.txt]
 
 On architectures that do not hide memoryless nodes, Linux will include only
 zones [nodes] with memory in the zonelists.  This means that for a memoryless
-node the "local memory node"--the node of the first zone in cpu's node's
+node the "local memory node"--the node of the first zone in CPU's node's
 zonelist--will not be the node itself.  Rather, it will be the node that the
 kernel selected as the nearest node with memory when it built the zonelists.
 So, default, local allocations will succeed with the kernel supplying the
@@ -128,22 +128,22 @@ does contain memory overflows.
 Some kernel allocations do not want or cannot tolerate this allocation fallback
 behavior.  Rather they want to be sure they get memory from the specified node
 or get notified that the node has no free memory.  This is usually the case when
-a subsystem allocates per cpu memory resources, for example.
+a subsystem allocates per CPU memory resources, for example.
 
 A typical model for making such an allocation is to obtain the node id of the
-node to which the "current cpu" is attached using one of the kernel's
-numa_node_id() or cpu_to_node() functions and then request memory from only
+node to which the "current CPU" is attached using one of the kernel's
+numa_node_id() or CPU_to_node() functions and then request memory from only
 the node id returned.  When such an allocation fails, the requesting subsystem
 may revert to its own fallback path.  The slab kernel memory allocator is an
-example of this.  Or, the subsystem may chose to disable or not to enable
+example of this.  Or, the subsystem may choose to disable or not to enable
 itself on allocation failure.  The kernel profiling subsystem is an example of
 this.
 
-If the architecture supports [does not hide] memoryless nodes, then cpus
+If the architecture supports--does not hide--memoryless nodes, then CPUs
 attached to memoryless nodes would always incur the fallback path overhead
 or some subsystems would fail to initialize if they attempted to allocated
-memory exclusively from the a node without memory.  To support such
+memory exclusively from a node without memory.  To support such
 architectures transparently, kernel subsystems can use the numa_mem_id()
 or cpu_to_mem() function to locate the "local memory node" for the calling or
-specified cpu.  Again, this is the same node from which default, local page
+specified CPU.  Again, this is the same node from which default, local page
 allocations will be attempted.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH 3/7] numa-x86_64-use-generic-percpu-var-numa_node_id-implementation-fix1

[Andrew Morton]

On Mon, 03 May 2010 11:05:18 -0400
Lee Schermerhorn <lee.schermerhorn@hp.com> wrote:

> Incremental patch 1 to
> numa-x86_64-use-generic-percpu-var-numa_node_id-implementation.patch
> in 28apr10 mmotm.
> 
> Use generic percpu numa_node variable only for x86_64.
> 
> x86_32 will require separate support.  Not sure it's worth it.
> 
> Signed-off-by: Lee Schermerhorn <lee.schermerhorn@hp.com>
> 
>  arch/x86/Kconfig |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> Index: linux-2.6.34-rc5-mmotm-100428-1653/arch/x86/Kconfig
> ===================================================================
> --- linux-2.6.34-rc5-mmotm-100428-1653.orig/arch/x86/Kconfig
> +++ linux-2.6.34-rc5-mmotm-100428-1653/arch/x86/Kconfig
> @@ -1720,7 +1720,7 @@ config HAVE_ARCH_EARLY_PFN_TO_NID
>  	depends on NUMA
>  
>  config USE_PERCPU_NUMA_NODE_ID
> -	def_bool y
> +	def_bool X86_64
>  	depends on NUMA
>  
>  menu "Power management and ACPI options"

i386 allmodconfig:

In file included from include/linux/gfp.h:7,
                 from include/linux/kmod.h:22,
                 from include/linux/module.h:13,
                 from include/linux/crypto.h:21,
                 from arch/x86/kernel/asm-offsets_32.c:7,
                 from arch/x86/kernel/asm-offsets.c:2:
include/linux/topology.h: In function 'numa_node_id':
include/linux/topology.h:248: error: implicit declaration of function 'cpu_to_node'

this patchset has been quite a PITA.  What happened?

Re: [PATCH 3/7] numa-x86_64-use-generic-percpu-var-numa_node_id-implementation-fix1

[Andrew Morton]

On Mon, 03 May 2010 11:05:18 -0400
Lee Schermerhorn <lee.schermerhorn@hp.com> wrote:

> Incremental patch 1 to
> numa-x86_64-use-generic-percpu-var-numa_node_id-implementation.patch
> in 28apr10 mmotm.
> 
> Use generic percpu numa_node variable only for x86_64.
> 
> x86_32 will require separate support.  Not sure it's worth it.
> 
> Signed-off-by: Lee Schermerhorn <lee.schermerhorn@hp.com>
> 
>  arch/x86/Kconfig |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> Index: linux-2.6.34-rc5-mmotm-100428-1653/arch/x86/Kconfig
> ===================================================================
> --- linux-2.6.34-rc5-mmotm-100428-1653.orig/arch/x86/Kconfig
> +++ linux-2.6.34-rc5-mmotm-100428-1653/arch/x86/Kconfig
> @@ -1720,7 +1720,7 @@ config HAVE_ARCH_EARLY_PFN_TO_NID
>  	depends on NUMA
>  
>  config USE_PERCPU_NUMA_NODE_ID
> -	def_bool y
> +	def_bool X86_64
>  	depends on NUMA
>  
>  menu "Power management and ACPI options"

i386 allmodconfig:

In file included from include/linux/gfp.h:7,
                 from include/linux/kmod.h:22,
                 from include/linux/module.h:13,
                 from include/linux/crypto.h:21,
                 from arch/x86/kernel/asm-offsets_32.c:7,
                 from arch/x86/kernel/asm-offsets.c:2:
include/linux/topology.h: In function 'numa_node_id':
include/linux/topology.h:248: error: implicit declaration of function 'cpu_to_node'

this patchset has been quite a PITA.  What happened?

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH 3/7] numa-x86_64-use-generic-percpu-var-numa_node_id-implementation-fix1

[Lee Schermerhorn]

On Fri, 2010-05-21 at 16:02 -0700, Andrew Morton wrote:
> On Mon, 03 May 2010 11:05:18 -0400
> Lee Schermerhorn <lee.schermerhorn@hp.com> wrote:
> 
> > Incremental patch 1 to
> > numa-x86_64-use-generic-percpu-var-numa_node_id-implementation.patch
> > in 28apr10 mmotm.
> > 
> > Use generic percpu numa_node variable only for x86_64.
> > 
> > x86_32 will require separate support.  Not sure it's worth it.
> > 
> > Signed-off-by: Lee Schermerhorn <lee.schermerhorn@hp.com>
> > 
> >  arch/x86/Kconfig |    2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > Index: linux-2.6.34-rc5-mmotm-100428-1653/arch/x86/Kconfig
> > ===================================================================
> > --- linux-2.6.34-rc5-mmotm-100428-1653.orig/arch/x86/Kconfig
> > +++ linux-2.6.34-rc5-mmotm-100428-1653/arch/x86/Kconfig
> > @@ -1720,7 +1720,7 @@ config HAVE_ARCH_EARLY_PFN_TO_NID
> >  	depends on NUMA
> >  
> >  config USE_PERCPU_NUMA_NODE_ID
> > -	def_bool y
> > +	def_bool X86_64
> >  	depends on NUMA
> >  
> >  menu "Power management and ACPI options"
> 
> i386 allmodconfig:
> 
> In file included from include/linux/gfp.h:7,
>                  from include/linux/kmod.h:22,
>                  from include/linux/module.h:13,
>                  from include/linux/crypto.h:21,
>                  from arch/x86/kernel/asm-offsets_32.c:7,
>                  from arch/x86/kernel/asm-offsets.c:2:
> include/linux/topology.h: In function 'numa_node_id':
> include/linux/topology.h:248: error: implicit declaration of function 'cpu_to_node'
> 
> this patchset has been quite a PITA.  What happened?

"fix3" to numa-x86_64-use-generic-percpu-var-numa_node_id-implementation
that I send out on May 17 should have fixed this.  That was in response
to Randy's NumaQ config that pulled the same error.  He verified that it
fixed the error.

You asked about the fix3 patch [offlist] on Wednesday, 19May.  Do you
have that one in your tree?

Lee

Re: [PATCH 3/7] numa-x86_64-use-generic-percpu-var-numa_node_id-implementation-fix1

[Lee Schermerhorn]

On Fri, 2010-05-21 at 16:02 -0700, Andrew Morton wrote:
> On Mon, 03 May 2010 11:05:18 -0400
> Lee Schermerhorn <lee.schermerhorn@hp.com> wrote:
> 
> > Incremental patch 1 to
> > numa-x86_64-use-generic-percpu-var-numa_node_id-implementation.patch
> > in 28apr10 mmotm.
> > 
> > Use generic percpu numa_node variable only for x86_64.
> > 
> > x86_32 will require separate support.  Not sure it's worth it.
> > 
> > Signed-off-by: Lee Schermerhorn <lee.schermerhorn@hp.com>
> > 
> >  arch/x86/Kconfig |    2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > Index: linux-2.6.34-rc5-mmotm-100428-1653/arch/x86/Kconfig
> > ===================================================================
> > --- linux-2.6.34-rc5-mmotm-100428-1653.orig/arch/x86/Kconfig
> > +++ linux-2.6.34-rc5-mmotm-100428-1653/arch/x86/Kconfig
> > @@ -1720,7 +1720,7 @@ config HAVE_ARCH_EARLY_PFN_TO_NID
> >  	depends on NUMA
> >  
> >  config USE_PERCPU_NUMA_NODE_ID
> > -	def_bool y
> > +	def_bool X86_64
> >  	depends on NUMA
> >  
> >  menu "Power management and ACPI options"
> 
> i386 allmodconfig:
> 
> In file included from include/linux/gfp.h:7,
>                  from include/linux/kmod.h:22,
>                  from include/linux/module.h:13,
>                  from include/linux/crypto.h:21,
>                  from arch/x86/kernel/asm-offsets_32.c:7,
>                  from arch/x86/kernel/asm-offsets.c:2:
> include/linux/topology.h: In function 'numa_node_id':
> include/linux/topology.h:248: error: implicit declaration of function 'cpu_to_node'
> 
> this patchset has been quite a PITA.  What happened?

"fix3" to numa-x86_64-use-generic-percpu-var-numa_node_id-implementation
that I send out on May 17 should have fixed this.  That was in response
to Randy's NumaQ config that pulled the same error.  He verified that it
fixed the error.

You asked about the fix3 patch [offlist] on Wednesday, 19May.  Do you
have that one in your tree?

Lee

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH 3/7] numa-x86_64-use-generic-percpu-var-numa_node_id-implementation-fix1

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 252 bytes --]

On Mon, 24 May 2010 10:09:32 EDT, Lee Schermerhorn said:
> 
> You asked about the fix3 patch [offlist] on Wednesday, 19May.  Do you
> have that one in your tree?
 
numa-introduce-numa_mem_id-effective-local-memory-node-id-fix3.patch
was in -mmotm0521.

[-- Attachment #2: Type: application/pgp-signature, Size: 227 bytes --]

Re: [PATCH 3/7] numa-x86_64-use-generic-percpu-var-numa_node_id-implementation-fix1

[Lee Schermerhorn]

On Mon, 2010-05-24 at 10:12 -0400, Valdis.Kletnieks@vt.edu wrote:
> On Mon, 24 May 2010 10:09:32 EDT, Lee Schermerhorn said:
> > 
> > You asked about the fix3 patch [offlist] on Wednesday, 19May.  Do you
> > have that one in your tree?
>  
> numa-introduce-numa_mem_id-effective-local-memory-node-id-fix3.patch
> was in -mmotm0521.

Right.  But, Andrew needs:
numa-x86_64-use-generic-percpu-var-numa_node_id-implementation-fix3 --
i.e., a fix to the 2nd patch of the percpu numa_*_id patch series.

Thanks,
Lee

Re: [PATCH 3/7] numa-x86_64-use-generic-percpu-var-numa_node_id-implementation-fix1

[Lee Schermerhorn]

On Mon, 2010-05-24 at 10:12 -0400, Valdis.Kletnieks@vt.edu wrote:
> On Mon, 24 May 2010 10:09:32 EDT, Lee Schermerhorn said:
> > 
> > You asked about the fix3 patch [offlist] on Wednesday, 19May.  Do you
> > have that one in your tree?
>  
> numa-introduce-numa_mem_id-effective-local-memory-node-id-fix3.patch
> was in -mmotm0521.

Right.  But, Andrew needs:
numa-x86_64-use-generic-percpu-var-numa_node_id-implementation-fix3 --
i.e., a fix to the 2nd patch of the percpu numa_*_id patch series.

Thanks,
Lee


--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH 3/7] numa-x86_64-use-generic-percpu-var-numa_node_id-implementation-fix1

[Andrew Morton]

On Mon, 24 May 2010 10:41:52 -0400
Lee Schermerhorn <Lee.Schermerhorn@hp.com> wrote:

> On Mon, 2010-05-24 at 10:12 -0400, Valdis.Kletnieks@vt.edu wrote:
> > On Mon, 24 May 2010 10:09:32 EDT, Lee Schermerhorn said:
> > > 
> > > You asked about the fix3 patch [offlist] on Wednesday, 19May.  Do you
> > > have that one in your tree?
> >  
> > numa-introduce-numa_mem_id-effective-local-memory-node-id-fix3.patch
> > was in -mmotm0521.
> 
> Right.  But, Andrew needs:
> numa-x86_64-use-generic-percpu-var-numa_node_id-implementation-fix3 --
> i.e., a fix to the 2nd patch of the percpu numa_*_id patch series.
> 

blah.

I have a
numa-x86_64-use-generic-percpu-var-numa_node_id-implementation-fix1.patch
and a fix3.  Was there ever a fix2?

Re: [PATCH 3/7] numa-x86_64-use-generic-percpu-var-numa_node_id-implementation-fix1

[Andrew Morton]

On Mon, 24 May 2010 10:41:52 -0400
Lee Schermerhorn <Lee.Schermerhorn@hp.com> wrote:

> On Mon, 2010-05-24 at 10:12 -0400, Valdis.Kletnieks@vt.edu wrote:
> > On Mon, 24 May 2010 10:09:32 EDT, Lee Schermerhorn said:
> > > 
> > > You asked about the fix3 patch [offlist] on Wednesday, 19May.  Do you
> > > have that one in your tree?
> >  
> > numa-introduce-numa_mem_id-effective-local-memory-node-id-fix3.patch
> > was in -mmotm0521.
> 
> Right.  But, Andrew needs:
> numa-x86_64-use-generic-percpu-var-numa_node_id-implementation-fix3 --
> i.e., a fix to the 2nd patch of the percpu numa_*_id patch series.
> 

blah.

I have a
numa-x86_64-use-generic-percpu-var-numa_node_id-implementation-fix1.patch
and a fix3.  Was there ever a fix2?

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH 3/7] numa-x86_64-use-generic-percpu-var-numa_node_id-implementation-fix1

[Lee Schermerhorn]

On Mon, 2010-05-24 at 11:34 -0700, Andrew Morton wrote:
> On Mon, 24 May 2010 10:41:52 -0400
> Lee Schermerhorn <Lee.Schermerhorn@hp.com> wrote:
> 
> > On Mon, 2010-05-24 at 10:12 -0400, Valdis.Kletnieks@vt.edu wrote:
> > > On Mon, 24 May 2010 10:09:32 EDT, Lee Schermerhorn said:
> > > > 
> > > > You asked about the fix3 patch [offlist] on Wednesday, 19May.  Do you
> > > > have that one in your tree?
> > >  
> > > numa-introduce-numa_mem_id-effective-local-memory-node-id-fix3.patch
> > > was in -mmotm0521.
> > 
> > Right.  But, Andrew needs:
> > numa-x86_64-use-generic-percpu-var-numa_node_id-implementation-fix3 --
> > i.e., a fix to the 2nd patch of the percpu numa_*_id patch series.
> > 
> 
> blah.
> 
> I have a
> numa-x86_64-use-generic-percpu-var-numa_node_id-implementation-fix1.patch
> and a fix3.  Was there ever a fix2?

Yes.  Here's a link to it in your 5/21 mmotm series:

http://userweb.kernel.org/~akpm/mmotm/broken-out/numa-x86_64-use-generic-percpu-var-numa_node_id-implementation-fix2.patch

Re: [PATCH 3/7] numa-x86_64-use-generic-percpu-var-numa_node_id-implementation-fix1

[Lee Schermerhorn]

On Mon, 2010-05-24 at 11:34 -0700, Andrew Morton wrote:
> On Mon, 24 May 2010 10:41:52 -0400
> Lee Schermerhorn <Lee.Schermerhorn@hp.com> wrote:
> 
> > On Mon, 2010-05-24 at 10:12 -0400, Valdis.Kletnieks@vt.edu wrote:
> > > On Mon, 24 May 2010 10:09:32 EDT, Lee Schermerhorn said:
> > > > 
> > > > You asked about the fix3 patch [offlist] on Wednesday, 19May.  Do you
> > > > have that one in your tree?
> > >  
> > > numa-introduce-numa_mem_id-effective-local-memory-node-id-fix3.patch
> > > was in -mmotm0521.
> > 
> > Right.  But, Andrew needs:
> > numa-x86_64-use-generic-percpu-var-numa_node_id-implementation-fix3 --
> > i.e., a fix to the 2nd patch of the percpu numa_*_id patch series.
> > 
> 
> blah.
> 
> I have a
> numa-x86_64-use-generic-percpu-var-numa_node_id-implementation-fix1.patch
> and a fix3.  Was there ever a fix2?

Yes.  Here's a link to it in your 5/21 mmotm series:

http://userweb.kernel.org/~akpm/mmotm/broken-out/numa-x86_64-use-generic-percpu-var-numa_node_id-implementation-fix2.patch


--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH 3/7] numa-x86_64-use-generic-percpu-var-numa_node_id-implementation-fix1

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 596 bytes --]

On Mon, 24 May 2010 10:41:52 EDT, Lee Schermerhorn said:
> On Mon, 2010-05-24 at 10:12 -0400, Valdis.Kletnieks@vt.edu wrote:
> > On Mon, 24 May 2010 10:09:32 EDT, Lee Schermerhorn said:
> > > 
> > > You asked about the fix3 patch [offlist] on Wednesday, 19May.  Do you
> > > have that one in your tree?
> >  
> > numa-introduce-numa_mem_id-effective-local-memory-node-id-fix3.patch
> > was in -mmotm0521.
> 
> Right.  But, Andrew needs:
> numa-x86_64-use-generic-percpu-var-numa_node_id-implementation-fix3 --
> i.e., a fix to the 2nd patch of the percpu numa_*_id patch series.

-ENOCAFFIENE ;)

[-- Attachment #2: Type: application/pgp-signature, Size: 227 bytes --]