Skip to contentSkip to conversation

- Allow architectures to increase size of MAX_NR_MEMBLKS

PATCH In review Jack Steiner 2 participants 3 messages Nov 5, 2003 – Nov 6, 2003

Subsystems (2)
lore
Share & tools
lore
#0 lore raw

PATCH 1/1 - Allow architectures to increase size of MAX_NR_MEMBLKS

This fixes a problem that occurs on system with >64 nodes.

Previously, MAX_NR_MEMBLKS was defined as BITS_PER_LONG. This patch allows an architecture to override this definition by defining a value in the arch-specific asm-xxx/mmzone.h file.

# This is a BitKeeper generated patch for the following project:
# Project Name: Linux kernel tree
# This patch format is intended for GNU patch command version 2.5 or higher. # This patch includes the following deltas:
# ChangeSet 1.1401 -> 1.1402
# include/linux/mmzone.h 1.45 -> 1.46
# include/asm-ia64/mmzone.h 1.6 -> 1.7
#
# The following is the BitKeeper ChangeSet Log
# --------------------------------------------
# 03/11/05 [email protected] 1.1402
# Allow architectures to supply their own value for MAX_NR_MEMBLKS. # The previous value (64) is not large enough for some systems. # --------------------------------------------
#

include/asm-ia64/mmzone.h +2 -0
diff -Nru a/include/asm-ia64/mmzone.h b/include/asm-ia64/mmzone.h
@@ -27,6 +27,8 @@
 # define NR_MEMBLKS		(NR_NODES)
 #endif
 
+#define MAX_NR_MEMBLKS		NR_MEMBLKS
+
 extern unsigned long max_low_pfn;
 
 #define pfn_valid(pfn)		(((pfn) < max_low_pfn) && ia64_pfn_valid(pfn))
include/linux/mmzone.h +8 -6
diff -Nru a/include/linux/mmzone.h b/include/linux/mmzone.h
@@ -287,12 +287,6 @@
 extern void setup_per_zone_pages_min(void);
 
 
-#ifdef CONFIG_NUMA
-#define MAX_NR_MEMBLKS	BITS_PER_LONG /* Max number of Memory Blocks */
-#else /* !CONFIG_NUMA */
-#define MAX_NR_MEMBLKS	1
-#endif /* CONFIG_NUMA */
-
 #include <linux/topology.h>
 /* Returns the number of the current Node. */
 #define numa_node_id()		(cpu_to_node(smp_processor_id()))
@@ -322,6 +316,14 @@
 #endif
 
 #endif /* !CONFIG_DISCONTIGMEM */
+
+#ifdef CONFIG_NUMA
+#ifndef MAX_NR_MEMBLKS
+#define MAX_NR_MEMBLKS	BITS_PER_LONG /* Max number of Memory Blocks */
+#endif
+#else /* !CONFIG_NUMA */
+#define MAX_NR_MEMBLKS	1
+#endif /* CONFIG_NUMA */
 
 #if NODES_SHIFT > MAX_NODES_SHIFT
 #error NODES_SHIFT > MAX_NODES_SHIFT
Signature · 4 lines
Thanks

Jack Steiner ([email protected])          651-683-5302
Principal Engineer                      SGI - Silicon Graphics, Inc.
#1 lore raw
Quoted 5 lines · Jack Steiner

This fixes a problem that occurs on system with >64 nodes.

Previously, MAX_NR_MEMBLKS was defined as BITS_PER_LONG. This patch allows an architecture to override this definition by defining a value in the arch-specific asm-xxx/mmzone.h file.

IMHO this is too much clutter. Just make it mandatory for the architectures to define their own MAX_NR_MEMBLKS in the numa case.

Or actually even better just have a

#ifndef MAX_NR_MEMBLKS
#define MAX_NR_MEMBLKS 1
#endif

in the generic code and let every architecture that wants to override it do so.

#2 lore raw
Quoted 10 lines · Christoph Hellwig
Quoted 5 lines · Jack Steiner

This fixes a problem that occurs on system with >64 nodes.

Previously, MAX_NR_MEMBLKS was defined as BITS_PER_LONG. This patch allows an architecture to override this definition by defining a value in the arch-specific asm-xxx/mmzone.h file.

IMHO this is too much clutter. Just make it mandatory for the architectures to define their own MAX_NR_MEMBLKS in the numa case.

Quoted 8 lines

Or actually even better just have a

#ifndef MAX_NR_MEMBLKS
#define MAX_NR_MEMBLKS 1
#endif

in the generic code and let every architecture that wants to override it do so.

I like this idea but wanted to minimize risk to other architectures at this point in 2.6.

AFAICT, the only other achitecture that would require change would be i386. I'm not familar with the i386 numa architecture. It looks like the change would be to add the definition of MAX_NR_MEMBLKS to include/asm-i386/numaq.h.

What is the value of MAX_NR_MEMBLKS for NUMAQ?

Are any architectures affected that I am overlooking???

I'm ok with either approach. What do other think??

Signature · 4 lines
Thanks

Jack Steiner ([email protected])          651-683-5302
Principal Engineer                      SGI - Silicon Graphics, Inc.