Re: [patch v2 for-4.0] mm, thp: really limit transparent hugepage allocation to local node
From: Vlastimil Babka <hidden>
Date: 2015-02-25 10:52:32
Also in:
lkml
On 02/25/2015 12:24 AM, David Rientjes wrote:
From: Greg Thelen <redacted>
Commit 077fcf116c8c ("mm/thp: allocate transparent hugepages on local
node") restructured alloc_hugepage_vma() with the intent of only
allocating transparent hugepages locally when there was not an effective
interleave mempolicy.
alloc_pages_exact_node() does not limit the allocation to the single
node, however, but rather prefers it. This is because __GFP_THISNODE is
not set which would cause the node-local nodemask to be passed. Without
it, only a nodemask that prefers the local node is passed.Oops, good catch. But I believe we have the same problem with khugepaged_alloc_page(), rendering the recent node determination and zone_reclaim strictness patches partially useless. Then I start to wonder about other alloc_pages_exact_node() users. Some do pass __GFP_THISNODE, others not - are they also mistaken? I guess the function is a misnomer - when I see "exact_node", I expect the __GFP_THISNODE behavior. I think to avoid such hidden catches, we should create alloc_pages_preferred_node() variant, change the exact_node() variant to pass __GFP_THISNODE, and audit and adjust all callers accordingly. 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.
quoted hunk ↗ jump to hunk
Fix this by passing __GFP_THISNODE and falling back to small pages when the allocation fails. Fixes: 077fcf116c8c ("mm/thp: allocate transparent hugepages on local node") Signed-off-by: Greg Thelen <redacted> Signed-off-by: David Rientjes <rientjes@google.com> --- v2: GFP_THISNODE actually defers compaction and reclaim entirely based on the combination of gfp flags. We want to try compaction and reclaim, so only set __GFP_THISNODE. We still set __GFP_NOWARN to suppress oom warnings in the kernel log when we can simply fallback to small pages. mm/mempolicy.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)diff --git a/mm/mempolicy.c b/mm/mempolicy.c --- a/mm/mempolicy.c +++ b/mm/mempolicy.c@@ -1985,7 +1985,10 @@ retry_cpuset: nmask = policy_nodemask(gfp, pol); if (!nmask || node_isset(node, *nmask)) { mpol_cond_put(pol); - page = alloc_pages_exact_node(node, gfp, order); + page = alloc_pages_exact_node(node, gfp | + __GFP_THISNODE | + __GFP_NOWARN, + order); goto out; } }
-- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>