[lkml]   [2003]   [Jan]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [rfc][patch] GFP_ZONEMASK vs. MAX_NR_ZONES
On Thu, Jan 30, 2003 at 06:18:16PM -0800, Matthew Dobson wrote:
> 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.

Erich Focht added a hack to NEC's tree so he can represent different
nodes on their IA64 machines as memory zones and most 64it architectures
really only needs a single zone (ZONE_NORMAL), so it might be an interesting
option to make all this stuff per-arch..

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:32    [W:0.030 / U:1.708 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site