From: "Jose A. Perez de Azpillaga" <azpijr@gmail.com>
To: David Hildenbrand <david@kernel.org>, Zi Yan <ziy@nvidia.com>,
Andrew Morton <akpm@linux-foundation.org>,
Lorenzo Stoakes <ljs@kernel.org>
Cc: Baolin Wang <baolin.wang@linux.alibaba.com>,
"Liam R. Howlett" <liam@infradead.org>,
Nico Pache <nico.pache@linux.dev>,
Ryan Roberts <ryan.roberts@arm.com>, Dev Jain <dev.jain@arm.com>,
Barry Song <baohua@kernel.org>, Lance Yang <lance.yang@linux.dev>,
Usama Arif <usama.arif@linux.dev>,
Kiryl Shutsemau <kas@kernel.org>, Rik van Riel <riel@surriel.com>,
Vlastimil Babka <vbabka@kernel.org>, Harry Yoo <harry@kernel.org>,
Jann Horn <jannh@google.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Joanne Koong <joannelkoong@gmail.com>,
"Jose A. Perez de Azpillaga" <azpijr@gmail.com>
Subject: [RFC PATCH 0/2] mm/huge_memory: find partially mapped shared folios with NO_PAGE_MAPCOUNT
Date: Wed, 11 Nov 2026 12:31:36 +0100 [thread overview]
Message-ID: <20261111113535.330078-1-azpijr@gmail.com> (raw)
With CONFIG_NO_PAGE_MAPCOUNT, an anon large folio mapped by several MMs
isn't seen as partially mapped while its mapcount stays at or above the
number of pages. If parent and child zap the same half of a THP after
fork(), that half is mapped by nobody, the folio is never queued for
deferred split, and the memory stays allocated until every mapper is
gone.
Patch 1 moves the split_underused_thp check out of
deferred_split_folio(). Patch 2 queues such folios as candidates and has
the shrinker walk the rmap to see which pages are still mapped.
512 MB of THPs with the same half zapped by every mapper, memory freed
by the shrinker:
before after
2M, 2 processes 0 MB 252 MB
2M, 3 processes 0 MB 237 MB
2M, 2 children + parent PMD 0 MB 244 MB
64K, 2 processes 0 MB 252 MB
64K, 3 processes 0 MB 252 MB
With patch 2 the shrinker reads shrink_underused itself, so folios
queued for the underused check aren't split anymore once it's turned
off.
David suggested a check from the shrinker for the opposite case in [1],
folios marked partially mapped by a PTE by PTE unmap. The walk in patch 2
could clear the flag there too, this series doesn't do it.
Questions:
- Is an rmap walk from the shrinker fine for this? Every CoW of a page
in a shared PTE-mapped folio queues a candidate, and so does the last
PMD mapper when it splits its PMD.
- The walk needs one bit per page, which is too much for the stack with
64K pages, so I used a static bitmap under a mutex. That serializes
the walks of all nodes and memcgs, and the mutex is taken with the
folio locked. Where should the bitmap live?
No selftest yet, I'll turn the reproducer into one if the approach is
ok.
Based on mm-new.
Tested on x86_64 in QEMU, so no numbers from real hardware or with
concurrent reclaim.
[1] https://lore.kernel.org/all/20261109220958.2071687-1-joannelkoong@gmail.com/
Jose A. Perez de Azpillaga (2):
mm/huge_memory: check split_underused_thp in the caller of
deferred_split_folio()
mm/huge_memory: detect partially mapped shared folios without per-page
mapcounts
mm/huge_memory.c | 86 ++++++++++++++++++++++++++++++++++++++++++++----
mm/rmap.c | 21 ++++++++++--
2 files changed, 98 insertions(+), 9 deletions(-)
--
2.56.0
next reply other threads:[~2026-11-11 11:35 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-11 11:31 Jose A. Perez de Azpillaga [this message]
2026-11-11 11:31 ` [RFC PATCH 1/2] mm/huge_memory: check split_underused_thp in the caller of deferred_split_folio() Jose A. Perez de Azpillaga
2026-11-11 11:31 ` [RFC PATCH 2/2] mm/huge_memory: detect partially mapped shared folios without per-page mapcounts Jose A. Perez de Azpillaga
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=20261111113535.330078-1-azpijr@gmail.com \
--to=azpijr@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=baohua@kernel.org \
--cc=baolin.wang@linux.alibaba.com \
--cc=david@kernel.org \
--cc=dev.jain@arm.com \
--cc=harry@kernel.org \
--cc=jannh@google.com \
--cc=joannelkoong@gmail.com \
--cc=kas@kernel.org \
--cc=lance.yang@linux.dev \
--cc=liam@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ljs@kernel.org \
--cc=nico.pache@linux.dev \
--cc=riel@surriel.com \
--cc=ryan.roberts@arm.com \
--cc=usama.arif@linux.dev \
--cc=vbabka@kernel.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
all inboxes | Powered by JetHome®