[PATCH v2 0/2] MM: Tighten control over zero-page remapping

[PATCH v2 0/2] MM: Tighten control over zero-page remapping

[Nico Pache (Red Hat)]

This patch series fixes a bug in KSM where the pages_to_scan limit is
bypassed and the policy (use_zero_pages) is ignored. It also gives users
further control of the zero-page remapping that occurs when a folio is
split.

Commit b1f202060afe ("mm: remap unused subpages to shared zeropage when
splitting isolated thp") added unconditional zero-page remapping when a
folio is split. This was sold as part of the underutilized shrinker, but
has a larger effect. Since this commit, all splits do this zero-page
scanning and remapping, even if the user has the underutilized shrinker
disabled.

This unconditional zero-page remapping was also problematic for KSM, as
when KSM would try to merge a page, it would split the folio and the
zero-page remapping would remap all zero-filled pages to the shared
zero-page bypassing the use_zero_pages policy. When the user had this
feature disabled, KSM would then waste cycles scanning these already
freed pages, causing little progress to be made, and KSMs performance to
degrade.

In this series we also gate the zero-page remapping behind
split_underused_thp (the sysfs for the underutilized shrinker). This
provides users with more control over this behavior, while also preventing
the KSM bug when it is enabled.

V2 Changes:
- Dropped ksm_is_running() and its EXPORT_SYMBOL_GPL (Lorenzo).
- Replaced the v1 approach with a narrower check:
  introduce current_is_ksmd() to detect ksmd and only skip zero-page
  remapping when the split is triggered by ksmd itself. This avoids
  disabling the underused THP shrinker's zero-page reclaim on VM_MERGEABLE
  mappings when the split is caused by something other than KSM.

V1: https://lore.kernel.org/all/20260609114619.144416-1-npache@redhat.com/
RFC: https://lore.kernel.org/all/20260508170509.640851-1-npache@redhat.com/

Signed-off-by: Nico Pache (Red Hat) <nico.pache@linux.dev>
---
Nico Pache (Red Hat) (2):
      mm/huge_memory.c: skip zero-page remapping when underused THP shrinker is disabled
      mm/ksm: prevent zero-page remapping during ksmd-triggered THP splits

 include/linux/ksm.h | 6 ++++++
 mm/huge_memory.c    | 3 ++-
 mm/ksm.c            | 5 +++++
 mm/migrate.c        | 3 +++
 4 files changed, 16 insertions(+), 1 deletion(-)
---
base-commit: a2abad0d7f453cc9902fc8bf7b871db5563a652c
base-tree: git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm mm-unstable
change-id: 20261025-b4-ksm_fixv2-2bf062e92946

Best regards,
--  
Nico Pache (Red Hat) <nico.pache@linux.dev>

[PATCH v2 1/2] mm/huge_memory.c: skip zero-page remapping when underused THP shrinker is disabled

[Nico Pache (Red Hat)]

The zero-page remapping in __folio_split() was added to support the
underused THP shrinker. When the shrinker is disabled via
shrink_underused, gate TTU_USE_SHARED_ZEROPAGE on split_underused_thp
to avoid scanning subpages for zero content unnecessarily.

Suggested-by: David Hildenbrand <david@kernel.org>
Fixes: b1f202060afe ("mm: remap unused subpages to shared zeropage when splitting isolated thp")
Signed-off-by: Nico Pache <nico.pache@linux.dev>
---
 mm/huge_memory.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index bd44d58e8684..2d56d1bff0ea 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);
 	}

-- 
2.56.0

Re: [PATCH v2 1/2] mm/huge_memory.c: skip zero-page remapping when underused THP shrinker is disabled

[Barry Song]

On Mon, Oct 26, 2026 at 1:40 AM Nico Pache (Red Hat)
<nico.pache@linux.dev> wrote:
>
> The zero-page remapping in __folio_split() was added to support the
> underused THP shrinker. When the shrinker is disabled via
> shrink_underused, gate TTU_USE_SHARED_ZEROPAGE on split_underused_thp
> to avoid scanning subpages for zero content unnecessarily.
>
> Suggested-by: David Hildenbrand <david@kernel.org>
> Fixes: b1f202060afe ("mm: remap unused subpages to shared zeropage when splitting isolated thp")
> Signed-off-by: Nico Pache <nico.pache@linux.dev>

is b1f202060afe a correct fixes tag? as
commit b1f202060afe has no even "split_underused_thp" there.

it was introduced by 81d3ff3c6f7 ("mm: add sysfs entry to disable
splitting underused THPs").

Re: [PATCH v2 1/2] mm/huge_memory.c: skip zero-page remapping when underused THP shrinker is disabled

[Nico Pache]

On 10/25/26 2:28 PM, Barry Song wrote:
> On Mon, Oct 26, 2026 at 1:40 AM Nico Pache (Red Hat)
> <nico.pache@linux.dev> wrote:
>>
>> The zero-page remapping in __folio_split() was added to support the
>> underused THP shrinker. When the shrinker is disabled via
>> shrink_underused, gate TTU_USE_SHARED_ZEROPAGE on split_underused_thp
>> to avoid scanning subpages for zero content unnecessarily.
>>
>> Suggested-by: David Hildenbrand <david@kernel.org>
>> Fixes: b1f202060afe ("mm: remap unused subpages to shared zeropage when splitting isolated thp")
>> Signed-off-by: Nico Pache <nico.pache@linux.dev>
> 
> is b1f202060afe a correct fixes tag? as
> commit b1f202060afe has no even "split_underused_thp" there.

I believe so. IIUC these two series were merged together. While 
81d3ff3c6f7 introduces the toggle, b1f202060afe is where the behavior 
started.

I guess you could argue that the Fixes should include both?

Not entirely sure!

-- Nico
> 
> it was introduced by 81d3ff3c6f7 ("mm: add sysfs entry to disable
> splitting underused THPs").

Re: [PATCH v2 1/2] mm/huge_memory.c: skip zero-page remapping when underused THP shrinker is disabled

[Barry Song]

On Mon, Oct 26, 2026 at 5:48 AM Nico Pache <nico.pache@linux.dev> wrote:
>
>
>
> On 10/25/26 2:28 PM, Barry Song wrote:
> > On Mon, Oct 26, 2026 at 1:40 AM Nico Pache (Red Hat)
> > <nico.pache@linux.dev> wrote:
> >>
> >> The zero-page remapping in __folio_split() was added to support the
> >> underused THP shrinker. When the shrinker is disabled via
> >> shrink_underused, gate TTU_USE_SHARED_ZEROPAGE on split_underused_thp
> >> to avoid scanning subpages for zero content unnecessarily.
> >>
> >> Suggested-by: David Hildenbrand <david@kernel.org>
> >> Fixes: b1f202060afe ("mm: remap unused subpages to shared zeropage when splitting isolated thp")
> >> Signed-off-by: Nico Pache <nico.pache@linux.dev>
> >
> > is b1f202060afe a correct fixes tag? as
> > commit b1f202060afe has no even "split_underused_thp" there.
>
> I believe so. IIUC these two series were merged together. While
> 81d3ff3c6f7 introduces the toggle, b1f202060afe is where the behavior
> started.
>
> I guess you could argue that the Fixes should include both?
>
> Not entirely sure!

Thanks for the clarification. I guess it's fine.

BTW, with the code below, we no longer add fully mapped
folios to deferred_split_folio. So the scanning code only
handles partially mapped folios to set up zero-page mappings
for their subpages.

I'm still not quite sure whether this is really harmful, though.
Am I missing something, or was there some discussion I missed?

void deferred_split_folio(struct folio *folio, bool partially_mapped)
{
        ...
        /*
         * Order 1 folios have no space for a deferred list, but we also
         * won't waste much memory by not adding them to the deferred list.
         */
        if (folio_order(folio) <= 1)
                return;

        if (!partially_mapped && !split_underused_thp)
                return;
}

Re: [PATCH v2 1/2] mm/huge_memory.c: skip zero-page remapping when underused THP shrinker is disabled

[Nico Pache]

On 10/25/26 10:52 PM, Barry Song wrote:
> On Mon, Oct 26, 2026 at 5:48 AM Nico Pache <nico.pache@linux.dev> wrote:
>>
>>
>>
>> On 10/25/26 2:28 PM, Barry Song wrote:
>>> On Mon, Oct 26, 2026 at 1:40 AM Nico Pache (Red Hat)
>>> <nico.pache@linux.dev> wrote:
>>>>
>>>> The zero-page remapping in __folio_split() was added to support the
>>>> underused THP shrinker. When the shrinker is disabled via
>>>> shrink_underused, gate TTU_USE_SHARED_ZEROPAGE on split_underused_thp
>>>> to avoid scanning subpages for zero content unnecessarily.
>>>>
>>>> Suggested-by: David Hildenbrand <david@kernel.org>
>>>> Fixes: b1f202060afe ("mm: remap unused subpages to shared zeropage when splitting isolated thp")
>>>> Signed-off-by: Nico Pache <nico.pache@linux.dev>
>>>
>>> is b1f202060afe a correct fixes tag? as
>>> commit b1f202060afe has no even "split_underused_thp" there.
>>
>> I believe so. IIUC these two series were merged together. While
>> 81d3ff3c6f7 introduces the toggle, b1f202060afe is where the behavior
>> started.
>>
>> I guess you could argue that the Fixes should include both?
>>
>> Not entirely sure!
> 
> Thanks for the clarification. I guess it's fine.
> 
> BTW, with the code below, we no longer add fully mapped
> folios to deferred_split_folio. So the scanning code only
> handles partially mapped folios to set up zero-page mappings
> for their subpages.
> 
> I'm still not quite sure whether this is really harmful, though.
> Am I missing something, or was there some discussion I missed?

The issue is not in the actual shrinker code or the deferred split list.

The issue is that any split leads to this zero-page remapping 
indiscriminate of the actual toggle. The same way this toggle is gating 
things going on the deferred split list, we should be gating the actual 
zero-page remapping too.

There were two pieces to the underutilized shrinker, first we check if a 
THP is underutilized, if so we split, and the split+remapping handles 
the freeing of that memory. However, functionally this also made ANY 
split do this zero page remapping, not just those coming from the shrinker.

-- Nico

> 
> void deferred_split_folio(struct folio *folio, bool partially_mapped)
> {
>          ...
>          /*
>           * Order 1 folios have no space for a deferred list, but we also
>           * won't waste much memory by not adding them to the deferred list.
>           */
>          if (folio_order(folio) <= 1)
>                  return;
> 
>          if (!partially_mapped && !split_underused_thp)
>                  return;
> }

Re: [PATCH v2 1/2] mm/huge_memory.c: skip zero-page remapping when underused THP shrinker is disabled

[Barry Song]

On Tue, Oct 27, 2026 at 4:02 AM Nico Pache <nico.pache@linux.dev> wrote:
>
>
>
> On 10/25/26 10:52 PM, Barry Song wrote:
> > On Mon, Oct 26, 2026 at 5:48 AM Nico Pache <nico.pache@linux.dev> wrote:
> >>
> >>
> >>
> >> On 10/25/26 2:28 PM, Barry Song wrote:
> >>> On Mon, Oct 26, 2026 at 1:40 AM Nico Pache (Red Hat)
> >>> <nico.pache@linux.dev> wrote:
> >>>>
> >>>> The zero-page remapping in __folio_split() was added to support the
> >>>> underused THP shrinker. When the shrinker is disabled via
> >>>> shrink_underused, gate TTU_USE_SHARED_ZEROPAGE on split_underused_thp
> >>>> to avoid scanning subpages for zero content unnecessarily.
> >>>>
> >>>> Suggested-by: David Hildenbrand <david@kernel.org>
> >>>> Fixes: b1f202060afe ("mm: remap unused subpages to shared zeropage when splitting isolated thp")
> >>>> Signed-off-by: Nico Pache <nico.pache@linux.dev>
> >>>
> >>> is b1f202060afe a correct fixes tag? as
> >>> commit b1f202060afe has no even "split_underused_thp" there.
> >>
> >> I believe so. IIUC these two series were merged together. While
> >> 81d3ff3c6f7 introduces the toggle, b1f202060afe is where the behavior
> >> started.
> >>
> >> I guess you could argue that the Fixes should include both?
> >>
> >> Not entirely sure!
> >
> > Thanks for the clarification. I guess it's fine.
> >
> > BTW, with the code below, we no longer add fully mapped
> > folios to deferred_split_folio. So the scanning code only
> > handles partially mapped folios to set up zero-page mappings
> > for their subpages.
> >
> > I'm still not quite sure whether this is really harmful, though.
> > Am I missing something, or was there some discussion I missed?
>
> The issue is not in the actual shrinker code or the deferred split list.
>
> The issue is that any split leads to this zero-page remapping
> indiscriminate of the actual toggle. The same way this toggle is gating
> things going on the deferred split list, we should be gating the actual
> zero-page remapping too.

I'm not quite sure this is true. The toggle prevents fully mapped
folios from being added to the deferred split list, so their
subpages won't have a chance to be remapped to zero.

For the remaining folios that are not fully mapped, or those
that were added to deferred_split_list while the toggle was
on and remain there after it is switched off, allowing
remapping to zeropfn doesn't seem to violate the toggle's
intention of preventing fully mapped folios from being added
to deferred_split_list.

Anyway, I don't have a strong opinion on this.

Thanks!
Barry

Re: [PATCH v2 1/2] mm/huge_memory.c: skip zero-page remapping when underused THP shrinker is disabled

[Nico Pache]

On 10/26/26 2:58 PM, Barry Song wrote:
> On Tue, Oct 27, 2026 at 4:02 AM Nico Pache <nico.pache@linux.dev> wrote:
>>
>>
>>
>> On 10/25/26 10:52 PM, Barry Song wrote:
>>> On Mon, Oct 26, 2026 at 5:48 AM Nico Pache <nico.pache@linux.dev> wrote:
>>>>
>>>>
>>>>
>>>> On 10/25/26 2:28 PM, Barry Song wrote:
>>>>> On Mon, Oct 26, 2026 at 1:40 AM Nico Pache (Red Hat)
>>>>> <nico.pache@linux.dev> wrote:
>>>>>>
>>>>>> The zero-page remapping in __folio_split() was added to support the
>>>>>> underused THP shrinker. When the shrinker is disabled via
>>>>>> shrink_underused, gate TTU_USE_SHARED_ZEROPAGE on split_underused_thp
>>>>>> to avoid scanning subpages for zero content unnecessarily.
>>>>>>
>>>>>> Suggested-by: David Hildenbrand <david@kernel.org>
>>>>>> Fixes: b1f202060afe ("mm: remap unused subpages to shared zeropage when splitting isolated thp")
>>>>>> Signed-off-by: Nico Pache <nico.pache@linux.dev>
>>>>>
>>>>> is b1f202060afe a correct fixes tag? as
>>>>> commit b1f202060afe has no even "split_underused_thp" there.
>>>>
>>>> I believe so. IIUC these two series were merged together. While
>>>> 81d3ff3c6f7 introduces the toggle, b1f202060afe is where the behavior
>>>> started.
>>>>
>>>> I guess you could argue that the Fixes should include both?
>>>>
>>>> Not entirely sure!
>>>
>>> Thanks for the clarification. I guess it's fine.
>>>
>>> BTW, with the code below, we no longer add fully mapped
>>> folios to deferred_split_folio. So the scanning code only
>>> handles partially mapped folios to set up zero-page mappings
>>> for their subpages.
>>>
>>> I'm still not quite sure whether this is really harmful, though.
>>> Am I missing something, or was there some discussion I missed?
>>
>> The issue is not in the actual shrinker code or the deferred split list.
>>
>> The issue is that any split leads to this zero-page remapping
>> indiscriminate of the actual toggle. The same way this toggle is gating
>> things going on the deferred split list, we should be gating the actual
>> zero-page remapping too.
> 
> I'm not quite sure this is true. The toggle prevents fully mapped
> folios from being added to the deferred split list, so their
> subpages won't have a chance to be remapped to zero.

Correct, but the deferred split list is not the only caller of 
folio_split(); all other callers get unconditional zero page remapping.

Additionally theres a difference between being fully mapped (and zero), 
and being partially unmapped. the zero-page remapping checks the content 
of the page. We could add folios to the deferred split list that are 
fully mapped but contain mostly zeros. With shrinker_underused turned 
off we no longer do any underutilized scans on reclaim, but other 
splitters (KSM, vmscan, migration, etc) will still scan the content of 
the memory and do the remapping whether this is on or off.
  >
> For the remaining folios that are not fully mapped, or those
> that were added to deferred_split_list while the toggle was
> on and remain there after it is switched off, allowing
> remapping to zeropfn doesn't seem to violate the toggle's
> intention of preventing fully mapped folios from being added
> to deferred_split_list.
> 
> Anyway, I don't have a strong opinion on this.

I think theres a misunderstanding here, but hopefully the above clears 
it up :) if not just lmk!

Cheers,
-- Nico


> 
> Thanks!
> Barry

[PATCH v2 2/2] mm/ksm: prevent zero-page remapping during ksmd-triggered THP splits

[Nico Pache (Red Hat)]

Since commit b1f202060afe ("mm: remap unused subpages to shared zeropage
when splitting isolated thp"), splitting an anonymous THP remaps all
zero-filled subpages to the shared zeropage via TTU_USE_SHARED_ZEROPAGE.
This flag is set unconditionally for every anonymous folio split,
including splits triggered by KSM.

When KSM is enabled with THP=always, this causes two regressions:

1. use_zero_pages=1: KSM calls try_to_merge_one_page() which triggers
   split_huge_page(). The split remaps all 512 zero-filled subpages to
   the shared zeropage at once, freeing the entire 2MB THP when KSM only
   intended to process a single 4KB page. This bypasses KSM's
   pages_to_scan rate limiting, causing ~1GB to be freed almost
   instantly.

2. use_zero_pages=0: The same split side-effect occurs through the
   stable/unstable tree merge paths. Each pages_to_scan iteration
   triggers an expensive split_huge_page() that silently frees 2MB,
   while the scanner wastes cycles on tree searches for zero-filled
   pages that were already freed as a side-effect.

Introduce current_is_ksmd(), which uses kthread_func() to check whether
the current task is the KSM scanning thread, and use it in
try_to_map_unused_to_zeropage() to skip zero-page remapping when the
split is triggered by ksmd.

Fixes: b1f202060afe ("mm: remap unused subpages to shared zeropage when splitting isolated thp")
Signed-off-by: Nico Pache (Red Hat) <nico.pache@linux.dev>
---
 include/linux/ksm.h | 6 ++++++
 mm/ksm.c            | 5 +++++
 mm/migrate.c        | 3 +++
 3 files changed, 14 insertions(+)

diff --git a/include/linux/ksm.h b/include/linux/ksm.h
index d39d0d5483a2..41c06a6abf60 100644
--- a/include/linux/ksm.h
+++ b/include/linux/ksm.h
@@ -17,6 +17,7 @@
 #ifdef CONFIG_KSM
 int ksm_madvise(struct vm_area_struct *vma, unsigned long start,
 		unsigned long end, int advice, vm_flags_t *vm_flags);
+bool current_is_ksmd(void);
 vma_flags_t ksm_vma_flags(struct mm_struct *mm, const struct file *file,
 			  vma_flags_t vma_flags);
 int ksm_enable_merge_any(struct mm_struct *mm);
@@ -144,6 +145,11 @@ static inline int ksm_madvise(struct vm_area_struct *vma, unsigned long start,
 	return 0;
 }
 
+static inline bool current_is_ksmd(void)
+{
+	return false;
+}
+
 static inline struct folio *ksm_might_need_to_copy(struct folio *folio,
 			struct vm_area_struct *vma, unsigned long addr)
 {
diff --git a/mm/ksm.c b/mm/ksm.c
index 910a1307ac9f..e3ab037b1ebe 100644
--- a/mm/ksm.c
+++ b/mm/ksm.c
@@ -2866,6 +2866,11 @@ static int ksm_scan_thread(void *nothing)
 	return 0;
 }
 
+bool current_is_ksmd(void)
+{
+	return kthread_func(current) == ksm_scan_thread;
+}
+
 static bool __ksm_should_add_vma(const struct file *file, vma_flags_t vma_flags)
 {
 	if (vma_flags_test(&vma_flags, VMA_MERGEABLE_BIT))
diff --git a/mm/migrate.c b/mm/migrate.c
index 7bdcdb57652f..c33ae3fa1043 100644
--- a/mm/migrate.c
+++ b/mm/migrate.c
@@ -305,6 +305,9 @@ static bool try_to_map_unused_to_zeropage(struct page_vma_mapped_walk *pvmw,
 	if (PageCompound(page) || PageHWPoison(page))
 		return false;
 
+	if (current_is_ksmd())
+		return false;
+
 	VM_BUG_ON_PAGE(!PageAnon(page), page);
 	VM_BUG_ON_PAGE(!PageLocked(page), page);
 	VM_BUG_ON_PAGE(pte_present(old_pte), page);

-- 
2.56.0