mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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


             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®