From: Matthew Dobson <colpatch@us.ibm.com>
To: linux-mm@kvack.org, linux-kernel <linux-kernel@vger.kernel.org>
Cc: "Martin J. Bligh" <mbligh@aracnet.com>,
William Lee Irwin III <wli@holomorphy.com>,
Andrea Arcangeli <andrea@suse.de>,
Andrew Morton <akpm@zip.com.au>,
Rik van Riel <riel@conectiva.com.br>
Subject: [rfc][patch] GFP_ZONEMASK vs. MAX_NR_ZONES
Date: Thu, 30 Jan 2003 18:18:16 -0800 [thread overview]
Message-ID: <3E39DCE8.8050101@us.ibm.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 1456 bytes --]
Whilst reading through some code for an unrelated patch the other day, I
stumbled across the build_zonelist* functions. It seemed to me that the
bounds on the loop seemed too large.
There are only 3 memory zones: DMA (__GFP_DMA = 0x01), NORMAL, & HIGHMEM
(__GFP_DMA = 0x02). Thus, GFP_ZONEMASK doesn't need to be 0x0f, but
only 0x03. My guess this was to leave room for future zones? In any
case, the loop in build_zonelists should almost certainly not go from
i=0..GFP_ZONEMASK. This instantiates 13 zones that are never used,
because there is no case that I could find where any zonemask above 0x02
is used. A zonemask of 0x03 would be DMA | HIGHMEM, but I could not
find an instance of that either, probably because it wouldn't make much
sense to request a chunk of memory from DMA & HIGHMEM.
By changing the value of GFP_ZONEMASK to accurately represent the number
of zones, and changing the size of the node_zonelists array to
MAX_NR_ZONES, we save ((156 * MAX_NUMNODES) + 42) bytes per pglist_data
structure (basically per node). This translates to 198 bytes on UP/SMP,
and 1290 bytes per node (MAX_NUMNODES=8) on NUMAQ. Not a stagerring
savings, but why waste it?
Can anyone point out why this patch would be wrong (other arch's using
it differently, fundamental misunderstanding on my part, etc)? BTW,
this patch boots for me on NUMAQ, and really should affect UP (except
for the slight size savings).
Cheers!
-Matt
[-- Attachment #2: zonelist_fix-2.5.59.patch --]
[-- Type: text/plain, Size: 1858 bytes --]
diff -Nur --exclude-from=/usr/src/.dontdiff linux-2.5.59-vanilla/include/linux/gfp.h linux-2.5.59-zonelist_fix/include/linux/gfp.h
--- linux-2.5.59-vanilla/include/linux/gfp.h Thu Jan 16 18:21:47 2003
+++ linux-2.5.59-zonelist_fix/include/linux/gfp.h Thu Jan 30 11:49:04 2003
@@ -7,7 +7,7 @@
/*
* GFP bitmasks..
*/
-/* Zone modifiers in GFP_ZONEMASK (see linux/mmzone.h - low four bits) */
+/* Zone modifiers in GFP_ZONEMASK (see linux/mmzone.h - low two bits) */
#define __GFP_DMA 0x01
#define __GFP_HIGHMEM 0x02
diff -Nur --exclude-from=/usr/src/.dontdiff linux-2.5.59-vanilla/include/linux/mmzone.h linux-2.5.59-zonelist_fix/include/linux/mmzone.h
--- linux-2.5.59-vanilla/include/linux/mmzone.h Thu Jan 16 18:21:34 2003
+++ linux-2.5.59-zonelist_fix/include/linux/mmzone.h Thu Jan 30 12:20:24 2003
@@ -162,7 +162,7 @@
struct zone *zones[MAX_NUMNODES * MAX_NR_ZONES + 1]; // NULL delimited
};
-#define GFP_ZONEMASK 0x0f
+#define GFP_ZONEMASK 0x03
/*
* The pg_data_t structure is used in machines with CONFIG_DISCONTIGMEM
@@ -178,7 +178,7 @@
struct bootmem_data;
typedef struct pglist_data {
struct zone node_zones[MAX_NR_ZONES];
- struct zonelist node_zonelists[GFP_ZONEMASK+1];
+ struct zonelist node_zonelists[MAX_NR_ZONES];
int nr_zones;
struct page *node_mem_map;
unsigned long *valid_addr_bitmap;
diff -Nur --exclude-from=/usr/src/.dontdiff linux-2.5.59-vanilla/mm/page_alloc.c linux-2.5.59-zonelist_fix/mm/page_alloc.c
--- linux-2.5.59-vanilla/mm/page_alloc.c Thu Jan 16 18:21:38 2003
+++ linux-2.5.59-zonelist_fix/mm/page_alloc.c Thu Jan 30 11:47:11 2003
@@ -962,7 +962,7 @@
local_node = pgdat->node_id;
printk("Building zonelist for node : %d\n", local_node);
- for (i = 0; i <= GFP_ZONEMASK; i++) {
+ for (i = 0; i < MAX_NR_ZONES; i++) {
struct zonelist *zonelist;
zonelist = pgdat->node_zonelists + i;
next reply other threads:[~2003-01-31 2:18 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-01-31 2:18 Matthew Dobson [this message]
2003-01-31 10:15 ` Christoph Hellwig
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3E39DCE8.8050101@us.ibm.com \
--to=colpatch@us.ibm.com \
--cc=akpm@zip.com.au \
--cc=andrea@suse.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mbligh@aracnet.com \
--cc=riel@conectiva.com.br \
--cc=wli@holomorphy.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox