Re: [PATCH rc5-mm1 1/3] mm-have-zonelist: fix memcg ooms

[Mel Gorman <mel@csn.ul.ie>]

On (12/03/08 13:34), Hugh Dickins didst pronounce:
> On Wed, 12 Mar 2008, Mel Gorman wrote:
> > On (11/03/08 21:12), Hugh Dickins didst pronounce:
> > > @@ -1454,9 +1453,10 @@ unsigned long try_to_free_mem_cgroup_pag
> > >  		.isolate_pages = mem_cgroup_isolate_pages,
> > >  	};
> > >  	struct zonelist *zonelist;
> > > -	int target_zone = gfp_zonelist(GFP_HIGHUSER_MOVABLE);
> > >  
> > > -	zonelist = &NODE_DATA(numa_node_id())->node_zonelists[target_zone];
> > > +	sc.gfp_mask = (gfp_mask & GFP_RECLAIM_MASK) |
> > > +			(GFP_HIGHUSER_MOVABLE & ~GFP_RECLAIM_MASK);
> > > +	zonelist = NODE_DATA(numa_node_id())->node_zonelists;
> > 
> > While it is clear you are setting the mask to include HIGHMEM-related flags,
> > it's not as clear to me why you alter the zonelist as well. target_zone was
> > already based on HIGHMEM so what are you fixing there?
> > 
> > It should still work as ->node_zonelists[0] is a zonelist suitable for node
> > fallback as opposed to node_zonelists[1] which is for GFP_THISNODE but
> > maybe this was not quite what you intended?
> > 
> > Probably something obvious that will hit me the second I push send :)
> 
> That bit wasn't a fix as such, it just came from not wanting to repeat
> GFP_HIGHUSER_MOVABLE in there: after I'd looked at gfp_zonelist, it
> appeared to be redundant in this context, so I preferred to cut out
> the target_zone, and let sc.gfp_mask handle it all.  That worries you?
> 

Only a little. If the layout of node_zonelists[] changes so that [0] does not
contain the node fallback list, it may cause a problem but I can't imagine why
such a situation would occur either. My initial concern was because I couldn't
see what difference the change made so assumed I must be missing something.

-- 
Mel Gorman
Part-time Phd Student                          Linux Technology Center
University of Limerick                         IBM Dublin Software Lab