linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Kefeng Wang <wangkefeng.wang@huawei.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Ryan Roberts <ryan.roberts@arm.com>,
	David Hildenbrand <david@redhat.com>, <willy@infradead.org>,
	Barry Song <baohua@kernel.org>, Hugh Dickins <hughd@google.com>,
	<linux-mm@kvack.org>, Kefeng Wang <wangkefeng.wang@huawei.com>
Subject: [PATCH] mm: set hugepage to false when anon mthp allocation
Date: Tue, 10 Sep 2024 22:06:25 +0800	[thread overview]
Message-ID: <20240910140625.175700-1-wangkefeng.wang@huawei.com> (raw)

When the hugepage parameter is true in vma_alloc_folio(), it indicates
that we only try allocation on preferred node if possible for PMD_ORDER,
but it could lead to lots of failures for large folio allocation,
luckily the hugepage parameter was deprecated since commit ddc1a5cbc05d
("mempolicy: alloc_pages_mpol() for NUMA policy without vma"), so no
effect on runtime behavior.

Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
---

Found the issue when backport mthp to inner kernel without ddc1a5cbc05d,
but for mainline, there is no issue, no clue why hugepage parameter was
retained, maybe just kill the parameter for mainline?

 mm/memory.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/mm/memory.c b/mm/memory.c
index b84443e689a8..89a15858348a 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -4479,7 +4479,7 @@ static struct folio *alloc_anon_folio(struct vm_fault *vmf)
 	gfp = vma_thp_gfp_mask(vma);
 	while (orders) {
 		addr = ALIGN_DOWN(vmf->address, PAGE_SIZE << order);
-		folio = vma_alloc_folio(gfp, order, vma, addr, true);
+		folio = vma_alloc_folio(gfp, order, vma, addr, false);
 		if (folio) {
 			if (mem_cgroup_charge(folio, vma->vm_mm, gfp)) {
 				count_mthp_stat(order, MTHP_STAT_ANON_FAULT_FALLBACK_CHARGE);
-- 
2.27.0



             reply	other threads:[~2024-09-10 14:06 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-09-10 14:06 Kefeng Wang [this message]
2024-09-10 14:18 ` Kefeng Wang
2024-09-13 10:36   ` Kefeng Wang
2024-10-09  9:15     ` Kefeng Wang
2024-10-09 10:44       ` Ryan Roberts
2024-10-09 14:28         ` David Hildenbrand
2024-10-10  1:13           ` Kefeng Wang

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=20240910140625.175700-1-wangkefeng.wang@huawei.com \
    --to=wangkefeng.wang@huawei.com \
    --cc=akpm@linux-foundation.org \
    --cc=baohua@kernel.org \
    --cc=david@redhat.com \
    --cc=hughd@google.com \
    --cc=linux-mm@kvack.org \
    --cc=ryan.roberts@arm.com \
    --cc=willy@infradead.org \
    /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