Re: [patch v2 for-4.0] mm, thp: really limit transparent hugepage allocation to local node

[Vlastimil Babka]

On 04/21/2015 09:31 AM, Aneesh Kumar K.V wrote:
> Vlastimil Babka <vbabka@xxxxxxx> writes:
>
> > On 25.2.2015 22:24, David Rientjes wrote:
> > > > alloc_pages_preferred_node() variant, change the exact_node() variant to pass
> > > > __GFP_THISNODE, and audit and adjust all callers accordingly.
> > > Sounds like that should be done as part of a cleanup after the 4.0 issues
> > > are addressed.  alloc_pages_exact_node() does seem to suggest that we want
> > > exactly that node, implying __GFP_THISNODE behavior already, so it would
> > > be good to avoid having this come up again in the future.
> >
> > Oh lovely, just found out that there's alloc_pages_node which should be the
> > preferred-only version, but in fact does not differ from
> > alloc_pages_exact_node
> > in any relevant way. I agree we should do some larger cleanup for next
> > version.
> >
> > > > Also, you pass __GFP_NOWARN but that should be covered by GFP_TRANSHUGE
> > > > already. Of course, nothing guarantees that hugepage == true implies that gfp
> > > > == GFP_TRANSHUGE... but current in-tree callers conform to that.
> > > Ah, good point, and it includes __GFP_NORETRY as well which means that
> > > this patch is busted.  It won't try compaction or direct reclaim in the
> > > page allocator slowpath because of this:
> > >
> > > 	/*
> > > 	 * GFP_THISNODE (meaning __GFP_THISNODE, __GFP_NORETRY and
> > > 	 * __GFP_NOWARN set) should not cause reclaim since the subsystem
> > > 	 * (f.e. slab) using GFP_THISNODE may choose to trigger reclaim
> > > 	 * using a larger set of nodes after it has established that the
> > > 	 * allowed per node queues are empty and that nodes are
> > > 	 * over allocated.
> > > 	 */
> > > 	if (IS_ENABLED(CONFIG_NUMA) &&
> > > 	    (gfp_mask & GFP_THISNODE) == GFP_THISNODE)
> > > 		goto nopage;
> > >
> > > Hmm.  It would be disappointing to have to pass the nodemask of the exact
> > > node that we want to allocate from into the page allocator to avoid using
> > > __GFP_THISNODE.
> >
> > Yeah.
> >
> > > There's a sneaky way around it by just removing __GFP_NORETRY from
> > > GFP_TRANSHUGE so the condition above fails and since the page allocator
> > > won't retry for such a high-order allocation, but that probably just
> > > papers over this stuff too much already.  I think what we want to do is
> >
> > Alternatively alloc_pages_exact_node() adds __GFP_THISNODE just to
> > node_zonelist() call and not to __alloc_pages() gfp_mask proper? Unless
> > __GFP_THISNODE
> > was given *also* in the incoming gfp_mask, this should give us the right
> > combination?
> > But it's also subtle....
> >
> > > cause the slab allocators to not use __GFP_WAIT if they want to avoid
> > > reclaim.
> >
> > Yes, the fewer subtle heuristics we have that include combinations of
> > flags (*cough*
> > GFP_TRANSHUGE *cough*), the better.
> >
> > > This is probably going to be a much more invasive patch than originally
> > > thought.
> >
> > Right, we might be changing behavior not just for slab allocators, but
> > also others using such
> > combination of flags.
>
> Any update on this ? Did we reach a conclusion on how to go forward here
> ?

I believe David's later version was merged already. Or what exactly are 
you asking about?

> -aneesh

--
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/