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
diff -ru linux/include/linux/mmzone.h linux_work/include/linux/mmzone.h
--- linux/include/linux/mmzone.h Thu Mar 15 19:03:47 2001
+++ linux_work/include/linux/mmzone.h Tue Mar 13 18:46:59 2001
@@ -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
diff -ru linux/mm/page_alloc.c linux_work/mm/page_alloc.c
--- linux/mm/page_alloc.c Mon Mar 12 13:33:02 2001
+++ linux_work/mm/page_alloc.c Mon Mar 12 13:00:08 2001
@@ -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;
On Thu, 15 Mar 2001, Anton Blanchard wrote:
> 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.
> +#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/
Hi,
On Thu, Mar 15, 2001 at 07:13:52PM +1100, Anton Blanchard wrote:
>
> 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
> 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