From: Joanne Koong <joannelkoong@gmail.com>
To: akpm@linux-foundation.org, david@kernel.org, ljs@kernel.org
Cc: usama.arif@linux.dev, hannes@cmpxchg.org, baohua@kernel.org,
alex@ghiti.fr, ziy@nvidia.com, baolin.wang@linux.alibaba.com,
liam@infradead.org, npache@redhat.com, ryan.roberts@arm.com,
dev.jain@arm.com, lance.yang@linux.dev, vbabka@kernel.org,
rppt@kernel.org, surenb@google.com, mhocko@suse.com,
willy@infradead.org, linux-mm@kvack.org
Subject: [PATCH v2 3/3] mm/memory: add anonymous mTHP folios to the deferred split list
Date: Wed, 16 Sep 2026 15:44:37 -0700 [thread overview]
Message-ID: <20260916224437.1164512-4-joannelkoong@gmail.com> (raw)
In-Reply-To: <20260916224437.1164512-1-joannelkoong@gmail.com>
Unlike for PMD-sized folios, an anonymous mTHP folio doesn't get added
to the deferred split list at fault or collapse time. As a result, a
fully mapped mTHP folio that is mostly zero-filled doesn't get split by
the deferred split shrinker when the system is under memory pressure.
At Meta we would like to deploy 2M THP=always on arm64 with 64k base
pages, as 2M gives the contpte benefits while the PMD size (512M) is too
big to use. Without underused splitting this causes memory regressions,
as the unused parts of those folios can never be broken down and
reclaimed.
Add anonymous mTHP folios to the deferred split list from
map_anon_folio_pte_nopf(), mirroring what map_anon_folio_pmd_nopf()
already does for PMD-sized folios. This covers both the fault path and
the khugepaged mTHP collapse path. If there is memory pressure, a
zero-filled mTHP can then be split with its zero pages remapped to the
shared zero page and reclaimed.
The preceding patch bounds what folios can get added to the deferred
split list. Nothing gets added at the default khugepaged/max_ptes_none,
and in cases where it is lowered, only folios with more pages than it
are added, so orders that could never be underused are left alone and
systems that enable only small mTHP orders are unaffected. For underused
splitting to happen, khugepaged/max_ptes_none has to be set below the
folio's page count.
To minimize overhead on the common order-0 fault path, the
deferred_split_folio() call is guarded by an inline folio_test_large()
check.
Suggested-by: Usama Arif <usama.arif@linux.dev>
Signed-off-by: Joanne Koong <joannelkoong@gmail.com>
---
mm/memory.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/mm/memory.c b/mm/memory.c
index 8b0c2c735d3d..1fe76f72868d 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -5406,6 +5406,8 @@ void map_anon_folio_pte_nopf(struct folio *folio, pte_t *pte,
folio_add_lru_vma(folio, vma);
set_ptes(vma->vm_mm, addr, pte, entry, nr_pages);
update_mmu_cache_range(NULL, vma, addr, pte, nr_pages);
+ if (folio_test_large(folio))
+ deferred_split_folio(folio, false);
}
static void map_anon_folio_pte_pf(struct folio *folio, pte_t *pte,
--
2.52.0
next prev parent reply other threads:[~2026-09-16 22:48 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-16 22:44 [PATCH v2 0/3] mm: split underused anonymous mTHP folios Joanne Koong
2026-09-16 22:44 ` [PATCH v2 1/3] mm/huge_memory: make thp_underused() work for " Joanne Koong
2026-09-16 22:44 ` [PATCH v2 2/3] mm/huge_memory: don't queue folios that can never be underused Joanne Koong
2026-09-16 22:44 ` Joanne Koong [this message]
2026-09-20 16:20 ` [PATCH v2 0/3] mm: split underused anonymous mTHP folios Lance Yang
2026-09-21 10:04 ` Barry Song
2026-09-21 10:08 ` Usama Arif
2026-09-21 10:22 ` David Hildenbrand (Arm)
2026-09-22 10:33 ` Kiryl Shutsemau
2026-09-21 10:12 ` David Hildenbrand (Arm)
2026-09-23 0:44 ` Joanne Koong
2026-09-23 6:00 ` Barry Song
2026-09-25 22:40 ` Joanne Koong
2026-09-23 9:44 ` David Hildenbrand (Arm)
2026-09-25 23:47 ` Joanne Koong
2026-09-28 8:03 ` Barry Song
2026-10-01 9:10 ` Joanne Koong
2026-09-28 19:20 ` David Hildenbrand (Arm)
2026-10-01 9:59 ` Joanne Koong
2026-09-21 10:23 ` David Hildenbrand (Arm)
2026-09-21 20:33 ` Joanne Koong
2026-09-22 18:59 ` David Hildenbrand (Arm)
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=20260916224437.1164512-4-joannelkoong@gmail.com \
--to=joannelkoong@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=alex@ghiti.fr \
--cc=baohua@kernel.org \
--cc=baolin.wang@linux.alibaba.com \
--cc=david@kernel.org \
--cc=dev.jain@arm.com \
--cc=hannes@cmpxchg.org \
--cc=lance.yang@linux.dev \
--cc=liam@infradead.org \
--cc=linux-mm@kvack.org \
--cc=ljs@kernel.org \
--cc=mhocko@suse.com \
--cc=npache@redhat.com \
--cc=rppt@kernel.org \
--cc=ryan.roberts@arm.com \
--cc=surenb@google.com \
--cc=usama.arif@linux.dev \
--cc=vbabka@kernel.org \
--cc=willy@infradead.org \
--cc=ziy@nvidia.com \
/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