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

[Lance Yang <lance.yang@linux.dev>]

On Tue, Jun 09, 2026 at 08:12:02PM +0800, xu.xin16@zte.com.cn 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 :)

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