Skip to contentSkip to conversation

: Only one memory zone for sparc64

PATCH In review Anton Blanchard 3 participants 4 messages Mar 15, 2001 – Mar 17, 2001

Subsystems (4)
Memory management MM core Page allocator MGLRU
lore
Share & tools
lore

Anton Blanchard

author
#0 lore raw

PATCH 1/1 : Only one memory zone for sparc64

Hi,

On sparc64 we dont care about the different memory zones and iterating through them all over the place only serves to waste CPU. I suspect this would be the case with some other architectures but for the moment I have just enabled it for sparc64.

With this patch I get close to a 1% improvement in dbench on the dual ultra60.

Anton

include/linux/mmzone.h +12 -0
diff -ru linux/include/linux/mmzone.h linux_work/include/linux/mmzone.h
@@ -63,7 +63,19 @@
 #define ZONE_DMA		0
 #define ZONE_NORMAL		1
 #define ZONE_HIGHMEM		2
+#ifdef __sparc_v9__
+#define MAX_NR_ZONES		1
+#define ZONE_NAMES		{ "DMA" }
+#define ZONE_BALANCE_RATIO	{ 32 }
+#define ZONE_BALANCE_MIN	{ 10 }
+#define ZONE_BALANCE_MAX	{ 255 }
+#else
 #define MAX_NR_ZONES		3
+#define ZONE_NAMES		{ "DMA", "Normal", "HighMem" }
+#define ZONE_BALANCE_RATIO	{ 32, 128, 128 }
+#define ZONE_BALANCE_MIN	{ 10, 10, 10 }
+#define ZONE_BALANCE_MAX	{ 255, 255, 255 }
+#endif
 
 /*
  * One allocation request operates on a zonelist. A zonelist
mm/page_alloc.c +4 -4
diff -ru linux/mm/page_alloc.c linux_work/mm/page_alloc.c
@@ -23,10 +23,10 @@
 int nr_inactive_dirty_pages;
 pg_data_t *pgdat_list;
 
-static char *zone_names[MAX_NR_ZONES] = { "DMA", "Normal", "HighMem" };
-static int zone_balance_ratio[MAX_NR_ZONES] = { 32, 128, 128, };
-static int zone_balance_min[MAX_NR_ZONES] = { 10 , 10, 10, };
-static int zone_balance_max[MAX_NR_ZONES] = { 255 , 255, 255, };
+static char *zone_names[MAX_NR_ZONES] = ZONE_NAMES;
+static int zone_balance_ratio[MAX_NR_ZONES] = ZONE_BALANCE_RATIO;
+static int zone_balance_min[MAX_NR_ZONES] = ZONE_BALANCE_MIN;
+static int zone_balance_max[MAX_NR_ZONES] = ZONE_BALANCE_MAX;
 
 struct list_head active_list;
 struct list_head inactive_dirty_list;
#1 lore raw
Quoted 7 lines · Anton Blanchard

On sparc64 we dont care about the different memory zones and iterating through them all over the place only serves to waste CPU. I suspect this would be the case with some other architectures but for the moment I have just enabled it for sparc64.

With this patch I get close to a 1% improvement in dbench on the dual ultra60.

1% ... I didn't expect Linux to take THIS much of a hit due to not using the zones on some architectures ...

I guess this is enough of a difference to make sure we don't do these extra iterations when they're not needed.

include/linux/mmzone.h line 72

Quoted 7 lines
include/linux/mmzone.h +7 -0
+#ifdef __sparc_v9__
+#define MAX_NR_ZONES		1
+#define ZONE_NAMES		{ "DMA" }
+#define ZONE_BALANCE_RATIO	{ 32 }
+#define ZONE_BALANCE_MIN	{ 10 }
+#define ZONE_BALANCE_MAX	{ 255 }
+#else

I guess it may be better to just have include/asm-<foo>/mmzone.h files for each architecture. Maybe even optionally behind an IFNDEF so we could start with almost empty files for each architecture and only fill in something when the values really need to be different ...

regards,

Rik
--
Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose...

		http://www.surriel.com/

http://www.conectiva.com/ http://distro.conectiva.com.br/

#2 lore raw
In reply to Anton Blanchard

Hi,

Quoted 8 lines · Anton Blanchard

On sparc64 we dont care about the different memory zones and iterating through them all over the place only serves to waste CPU. I suspect this would be the case with some other architectures but for the moment I have just enabled it for sparc64.

With this patch I get close to a 1% improvement in dbench on the dual ultra60.

I'd be surprised if dbench was anything other than disk-bound on most systems. On any of my machines, the standard error of a single dbench run is *way* larger than 1%, and I'd expect to have to run the benchmark a dozen times to get a confidence interval small enough to detect a 1% performance change: are your runs repeatable enough to be this sensitive to the effect of the allocator?

Cheers,
Stephen

author
#3 lore raw
In reply to Anton Blanchard
Quoted 7 lines

I'd be surprised if dbench was anything other than disk-bound on most systems. On any of my machines, the standard error of a single dbench run is *way* larger than 1%, and I'd expect to have to run the benchmark a dozen times to get a confidence interval small enough to detect a 1% performance change: are your runs repeatable enough to be this sensitive to the effect of the allocator?

With 2G RAM and:

kill -STOP <kupdated>
echo "90 64 64 256 5120 30720 95 0 0" > /proc/sys/vm/bdflush

I dont do one single disk interrupt for a dbench 60 :) At this stage dbench runs become more repeatable.

Anton