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