Re: [PATCH 6/6] Use one zonelist that is filtered by nodemask

From: Mel Gorman
Date: Sun Nov 11 2007 - 09:16:22 EST


On (09/11/07 09:26), Christoph Lameter didst pronounce:
> On Fri, 9 Nov 2007, Lee Schermerhorn wrote:
>
> > > On the other hand, if we call alloc_pages() with GFP_THISNODE set, there
> > > is no nid to base the allocation on, so we "fallback" to numa_node_id()
> > > [ almost like the nid had been specified as -1 ].
> > >
> > > So I guess this is logical -- but I wonder, do we have any callers of
> > > alloc_pages(GFP_THISNODE) ? It seems like an odd thing to do, when
> > > alloc_pages_node() exists?
> >
> > I don't know if we have any current callers that do this, but absent any
> > documentation specifying otherwise, Mel's implementation matches what
> > I'd expect the behavior to be if I DID call alloc_pages with 'THISNODE.
> > However, we could specify that THISNODE is ignored in __alloc_pages()
> > and recommend the use of alloc_pages_node() passing numa_node_id() as
> > the nid parameter to achieve the behavior. This would eliminate the
> > check for 'THISNODE in __alloc_pages(). Just mask it off before calling
> > down to __alloc_pages_internal().
> >
> > Does this make sense?
>
> I like consistency. If someone absolutely wants a local page then
> specifying GFP_THISNODE to __alloc_pages is okay. Leave as is I guess.
>

Agreed.

> What happens though if an MPOL_BIND policy is in effect? The node used
> must then be the nearest node from the policy mask....
>

If MPOL_BIND is in effect, the allocation will be filtered based on the
current allowed nodemask. If they specify THISNODE and the specified
node or current node is not in the mask, I would expect the allocation
to fail. Is that unexpected to anybody?

--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab
-
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/