Re: [PATCH] fix GFP zone modifier interators

[Andy Whitcroft]

--On 24 June 2004 15:23 -0700 Andrew Morton <akpm@xxxxxxxx> wrote:

> Andy Whitcroft <apw@xxxxxxxxxxxx> wrote:
> > For each node there are a defined list of MAX_NR_ZONES zones.
> > These are selected as a result of the __GFP_DMA and __GFP_HIGHMEM
> > zone modifier flags being passed to the memory allocator as part of
> > the GFP mask.  Each node has a set of zone lists, node_zonelists,
> > which defines the list and order of zones to scan for each flag
> > combination.  When initialising these lists we iterate over
> > modifier combinations 0 .. MAX_NR_ZONES.  However, this is only
> > correct when there are at most ZONES_SHIFT flags.  If another flag
> > is introduced zonelists for it would not be initialised.
>
> I don't get it.  If you were going to add a new zone, identified by
> __GFP_WHATEVER then you'd need to increase MAX_NR_ZONES
> anyway, wouldn't you?
>
> I'm sure you're right, but I haven't worked on this stuff in months and
> it's obscure.  Care to explain a little more?

If you added a new zone you would increase MAX_NR_ZONES from 3 to 4, you 
would add __GFP_NEWONE as 0x4 as those are bit flags and GFP_ZONEMASK to 
0x7.  Now to build the zonelists we need to scan from 0-7 in 'Zone 
Modifier' space to cover all the combinations, but MAX_NR_ZONES is only 4. 
So we don't build the zonelists for them.

There is a question of whether we should be scanning 0..MAX_NR_ZONES and 
assuming the selector is 1<<N.  That would mean that there would be no 
support for the use of more than one such 'Zone Modifier' at a time. 
Currently there is no such usage.  My gut feeling is to not rule them out 
and to build the zonelists for all combinations (even if they are empty).

> > This patch introduces GFP_ZONEMODS (based on GFP_ZONEMASK) as a
> > bound for the number of modifier combinations.
>
> The "ZONEMODS" identifier doesn't really grab me.  ZONETYPES, or
> something?

Zone types is fine with me.  I took the name from the comments in mmzone.h, 
I have no attachment to it.

> Either way, please add a big fat comment over it, explaining to the poor
> reader what its semantic meaning is.

I'll add some more commentary and see how it looks.

-apw


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/