Re: [PATCH mm-unstable v1 2/3] mm/migrate.c: Prevent folio splitting from interacting with KSM

[Nico Pache]

On Tue, Jun 9, 2026 at 6:12 AM <xu.xin16@xxxxxxxxxx> wrote:
>
> >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.
> >
>
> Why do you see it as regressions?

Since the zero-page remapping was introduced our test has shown the
following behavior changes:

With use_zero_pages=0, the merge rate drops from 60MB/s to ~6 MB/s
even after raising pages_to_scan. The KSM merging is now much slower
and CPU utilization has increased.

With use_zero_pages=1, ~1 GB is freed almost instantly, and it no
longer respects the pages_to_scan behavior.

Even with just this patch (1 & 2) or the RFC linked in the cover
letter, the issue no longer occurs.

>
> AFAIU, KSM and THP do often conflict with each other. THP tries hard to collapse
> a huge page (which may contain many zero pages). If KSM is enabled and part of
> that huge page is mergeable, it can easily be split by KSM, rendering THP's
> efforts futile.
>
> Therefore, in our actual production environment, we typically avoid making the
> same region both KSM mergeable and THP always.

THP=always is a global setting used in many production environments,
so these features now interact very poorly together.

Let me know if that answers your question!

Cheers,
-- Nico

>
>
> >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.
> >
> >Fix this by restricting TTU_USE_SHARED_ZEROPAGE being set in the case that
> >KSM is running and the VMA has VM_MERGEABLE.
>