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 7:06 AM Lance Yang <lance.yang@xxxxxxxxx> wrote:
>
>
> On Tue, Jun 09, 2026 at 08:12:02PM +0800, 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?
> >
> >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.
>
> Right, some setups may choose to avoid using KSM and THP always on the
> same region. But that is not something the kernel can assume :)
>
> David noted in the RFC that QEMU may use both MADV_HUGEPAGE and
> MADV_MERGEABLE, while KSM can be enabled later system-wide.
>
> And I think Nico means something different from KSM spliting THPs in
> general.
>
> KSM has been able to split THP before. the new part from b1f202060afe is
> that a KSM-triggered split can also remap zero-filled subpages to the
> shared zeropage, outside KSM's own use_zero_pages/pages_to_scan controls.
>
> Maybe the changelog could spell that out :)

Yeah maybe I didnt properly explain that :p

After some thought I still think the alternative approach i mentioned
in the RFC may be better.

ie) prevent the zero-page merging that results from KSM splitting a
folio. The check we add here is more general and will skip this
zero-page merging with all MERGEABLE mappings, not just those causing
the issue (the KSM splitting). The result is that even migrations, etc
that are also MERGEABLE will be skipped needlessly.

If we use this approach we also don't need the first patch of the series.

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.
> >
>