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

[David Hildenbrand (Arm)]

On 6/9/26 14:57, Nico Pache wrote:
> 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.

Red Hat documents, though, that both things in combination are shaky:

"As KSM can reduce the occurrence of transparent huge pages, you may want to
disable it before enabling THP." [1]

(for RHEL 6, but nothing should have changed in that regard)

But yeah, having KSM and THP enabled at the same time is not uncommon.

[1]
https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/6/html/virtualization_tuning_and_optimization_guide/sect-virtualization_tuning_optimization_guide-memory-huge_pages

-- 
Cheers,

David