From: David Rientjes <rientjes@google.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Michal Hocko <mhocko@suse.cz>, Vlastimil Babka <vbabka@suse.cz>,
Johannes Weiner <hannes@cmpxchg.org>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: [patch] mm, memcg: sync allocation and memcg charge gfp flags for thp fix fix
Date: Thu, 2 Apr 2015 18:41:18 -0700 (PDT) [thread overview]
Message-ID: <alpine.DEB.2.10.1504021836180.20229@chino.kir.corp.google.com> (raw)
In-Reply-To: <20150318161407.GP17241@dhcp22.suse.cz>
"mm, memcg: sync allocation and memcg charge gfp flags for THP" in -mm
introduces a formal to pass the gfp mask for khugepaged's hugepage
allocation. This is just too ugly to live.
alloc_hugepage_gfpmask() cannot differ between NUMA and UMA configs by
anything in GFP_RECLAIM_MASK, which is the only thing that matters for
memcg reclaim, so just determine the gfp flags once in
collapse_huge_page() and avoid the complexity.
Signed-off-by: David Rientjes <rientjes@google.com>
---
-mm: intended to be folded into
mm-memcg-sync-allocation-and-memcg-charge-gfp-flags-for-thp.patch
mm/huge_memory.c | 21 ++++++++-------------
1 file changed, 8 insertions(+), 13 deletions(-)
diff --git a/mm/huge_memory.c b/mm/huge_memory.c
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -2373,16 +2373,12 @@ static bool khugepaged_prealloc_page(struct page **hpage, bool *wait)
}
static struct page *
-khugepaged_alloc_page(struct page **hpage, gfp_t *gfp, struct mm_struct *mm,
+khugepaged_alloc_page(struct page **hpage, gfp_t gfp, struct mm_struct *mm,
struct vm_area_struct *vma, unsigned long address,
int node)
{
VM_BUG_ON_PAGE(*hpage, *hpage);
- /* Only allocate from the target node */
- *gfp = alloc_hugepage_gfpmask(khugepaged_defrag(), __GFP_OTHER_NODE) |
- __GFP_THISNODE;
-
/*
* Before allocating the hugepage, release the mmap_sem read lock.
* The allocation can take potentially a long time if it involves
@@ -2391,7 +2387,7 @@ khugepaged_alloc_page(struct page **hpage, gfp_t *gfp, struct mm_struct *mm,
*/
up_read(&mm->mmap_sem);
- *hpage = alloc_pages_exact_node(node, *gfp, HPAGE_PMD_ORDER);
+ *hpage = alloc_pages_exact_node(node, gfp, HPAGE_PMD_ORDER);
if (unlikely(!*hpage)) {
count_vm_event(THP_COLLAPSE_ALLOC_FAILED);
*hpage = ERR_PTR(-ENOMEM);
@@ -2445,18 +2441,13 @@ static bool khugepaged_prealloc_page(struct page **hpage, bool *wait)
}
static struct page *
-khugepaged_alloc_page(struct page **hpage, gfp_t *gfp, struct mm_struct *mm,
+khugepaged_alloc_page(struct page **hpage, gfp_t gfp, struct mm_struct *mm,
struct vm_area_struct *vma, unsigned long address,
int node)
{
up_read(&mm->mmap_sem);
VM_BUG_ON(!*hpage);
- /*
- * khugepaged_alloc_hugepage is doing the preallocation, use the same
- * gfp flags here.
- */
- *gfp = alloc_hugepage_gfpmask(khugepaged_defrag(), 0);
return *hpage;
}
#endif
@@ -2495,8 +2486,12 @@ static void collapse_huge_page(struct mm_struct *mm,
VM_BUG_ON(address & ~HPAGE_PMD_MASK);
+ /* Only allocate from the target node */
+ gfp = alloc_hugepage_gfpmask(khugepaged_defrag(), __GFP_OTHER_NODE) |
+ __GFP_THISNODE;
+
/* release the mmap_sem read lock. */
- new_page = khugepaged_alloc_page(hpage, &gfp, mm, vma, address, node);
+ new_page = khugepaged_alloc_page(hpage, gfp, mm, vma, address, node);
if (!new_page)
return;
next prev parent reply other threads:[~2015-04-03 1:41 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-16 14:08 [PATCH] mm, memcg: sync allocation and memcg charge gfp flags for THP Michal Hocko
2015-03-18 14:34 ` Vlastimil Babka
2015-03-18 15:02 ` Michal Hocko
2015-03-18 15:40 ` Vlastimil Babka
2015-03-18 15:59 ` Michal Hocko
2015-03-18 16:09 ` Vlastimil Babka
2015-03-18 16:14 ` [PATCH -v2] " Michal Hocko
2015-04-03 1:41 ` David Rientjes [this message]
2015-04-03 8:38 ` [patch] mm, memcg: sync allocation and memcg charge gfp flags for thp fix fix Vlastimil Babka
2015-04-03 10:50 ` Michal Hocko
2015-04-04 1:34 ` [PATCH -v2] mm, memcg: sync allocation and memcg charge gfp flags for THP David Rientjes
2015-04-07 12:19 ` Michal Hocko
[not found] <058201d06de5$9e15edc0$da41c940$@alibaba-inc.com>
2015-04-03 8:14 ` [patch] mm, memcg: sync allocation and memcg charge gfp flags for thp fix fix Hillf Danton
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.DEB.2.10.1504021836180.20229@chino.kir.corp.google.com \
--to=rientjes@google.com \
--cc=akpm@linux-foundation.org \
--cc=hannes@cmpxchg.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.cz \
--cc=vbabka@suse.cz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).