[lkml]   [2015]   [Apr]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [patch v2 for-4.0] mm, thp: really limit transparent hugepage allocation to local node
Vlastimil Babka <> 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_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.
>> */
>> (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
> 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
> 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


 \ /
  Last update: 2015-04-21 09:41    [W:0.117 / U:0.068 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site