From: sashiko-bot@kernel.org
To: "Nico Pache (Red Hat)" <nico.pache@linux.dev>, linux-mm@kvack.org
Cc: "Andrew Morton" <akpm@linux-foundation.org>,
"David Hildenbrand" <david@kernel.org>, "Zi Yan" <ziy@nvidia.com>,
"Baolin Wang" <baolin.wang@linux.alibaba.com>,
"Liam R. Howlett" <liam@infradead.org>,
"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>, "Yu Zhao" <yuzhao@google.com>,
"Xu Xin" <xu.xin@linux.dev>,
"Chengming Zhou" <chengming.zhou@linux.dev>,
"Matthew Brost" <matthew.brost@intel.com>,
"Joshua Hahn" <joshua.hahnjy@gmail.com>,
"Byungchul Park" <byungchul@sk.com>,
"Gregory Price" <gourry@gourry.net>,
"Ying Huang" <ying.huang@linux.alibaba.com>,
"Alistair Popple" <apopple@nvidia.com>,
"Usama Arif" <usamaarif642@gmail.com>,
aarcange@redhat.com
Subject: Re: [PATCH v2 1/2] mm/huge_memory.c: skip zero-page remapping when underused THP shrinker is disabled
Date: Mon, 26 Oct 2026 17:41:15 +0000 [thread overview]
Message-ID: <sashiko-outbox-185584@kernel.org> (raw)
In-Reply-To: <20261025-b4-ksm_fixv2-v2-1-8b61ad0491f1@linux.dev>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] mm: pointless underused THP splits in deferred_split_scan()
--
commit ebf8a156b1409b53d86c1c5c41f9ce1ca1b64265
Author: Nico Pache (Red Hat) <nico.pache@linux.dev>
mm/huge_memory.c: skip zero-page remapping when underused THP shrinker is disabled
This commit gates shared zeropage remapping in __folio_freeze_split_anon() on
split_underused_thp so subpages are not scanned for zero content during THP
splits when the underused shrinker is disabled.
> diff --git a/mm/huge_memory.c b/mm/huge_memory.c
> index bd44d58e86845..2d56d1bff0eab 100644
> --- a/mm/huge_memory.c
> +++ b/mm/huge_memory.c
> @@ -4104,7 +4104,8 @@ static int __folio_freeze_split_anon(struct folio *folio,
> out_no_split:
> local_irq_enable();
> if (anon_vma) {
> - if (!ret && !folio_is_device_private(folio))
> + if (!ret && !folio_is_device_private(folio) &&
> + split_underused_thp)
> ttu_flags = TTU_USE_SHARED_ZEROPAGE;
> remap_anon_folio(folio, 1 << old_order, ttu_flags);
> }
[Severity: Medium]
What happens in deferred_split_scan() if shrink_underused is disabled at
runtime after anonymous folios have already been queued onto
deferred_split_lru?
Since split_underused_thp defaults to true at boot, anonymous folios
allocated via map_anon_folio_pmd_nopf() or collapsed via collapse_huge_page()
are queued via deferred_split_folio(folio, false) without setting the
partially mapped flag. If a user later sets shrink_underused to 0 (setting
split_underused_thp to false), those previously queued folios remain on
deferred_split_lru.
When memory reclaim subsequently runs deferred_split_scan(), the
!folio_test_partially_mapped(folio) path does not check split_underused_thp:
mm/huge_memory.c:deferred_split_scan() {
...
if (!folio_test_partially_mapped(folio)) {
if (folio_test_mlocked(folio))
goto next;
underused = thp_underused(folio);
if (!underused)
goto next;
}
if (!folio_trylock(folio))
goto requeue;
if (!split_folio(folio)) {
did_split = true;
if (underused)
count_vm_event(THP_UNDERUSED_SPLIT_PAGE);
split++;
}
...
}
Because __folio_freeze_split_anon() now omits the shared zeropage flag when
split_underused_thp is false, remap_anon_folio() -> remove_migration_ptes()
skips try_to_map_unused_to_zeropage() and remaps all subpages (including
zero-filled ones) back to their split order-0 folios.
Doesn't this cause deferred_split_scan() to still scan subpages via
thp_underused(), shatter the huge page into order-0 pages, and increment the
underused split counters while freeing zero pages? Should
deferred_split_scan() also check split_underused_thp (for example, skipping
non-partially-mapped folios via goto next when !split_underused_thp)?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261025-b4-ksm_fixv2-v2-0-8b61ad0491f1@linux.dev?part=1
next prev parent reply other threads:[~2026-10-26 17:41 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-25 17:39 [PATCH v2 0/2] MM: Tighten control over zero-page remapping Nico Pache (Red Hat)
2026-10-25 17:39 ` [PATCH v2 1/2] mm/huge_memory.c: skip zero-page remapping when underused THP shrinker is disabled Nico Pache (Red Hat)
2026-10-25 20:28 ` Barry Song
2026-10-25 21:48 ` Nico Pache
2026-10-26 4:52 ` Barry Song
2026-10-26 20:02 ` Nico Pache
2026-10-26 20:58 ` Barry Song
2026-10-26 21:33 ` Nico Pache
2026-10-26 17:41 ` sashiko-bot [this message]
2026-10-25 17:39 ` [PATCH v2 2/2] mm/ksm: prevent zero-page remapping during ksmd-triggered THP splits Nico Pache (Red Hat)
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=sashiko-outbox-185584@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=aarcange@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=apopple@nvidia.com \
--cc=baohua@kernel.org \
--cc=baolin.wang@linux.alibaba.com \
--cc=byungchul@sk.com \
--cc=chengming.zhou@linux.dev \
--cc=david@kernel.org \
--cc=dev.jain@arm.com \
--cc=gourry@gourry.net \
--cc=joshua.hahnjy@gmail.com \
--cc=kas@kernel.org \
--cc=lance.yang@linux.dev \
--cc=liam@infradead.org \
--cc=linux-mm@kvack.org \
--cc=matthew.brost@intel.com \
--cc=nico.pache@linux.dev \
--cc=ryan.roberts@arm.com \
--cc=sashiko-reviews@lists.linux.dev \
--cc=usama.arif@linux.dev \
--cc=usamaarif642@gmail.com \
--cc=xu.xin@linux.dev \
--cc=ying.huang@linux.alibaba.com \
--cc=yuzhao@google.com \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.