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

[Zi Yan]

On 9 Jun 2026, at 9:47, 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.
>
> Understood. You're saying that the additional processing action in split_huge_page
> (remap unused subpages to shared zeropage) increases the scanning cost of ksmd.
>
> However, I still wouldn't simply classify this as a performance regression,
> because commit b1f202060afe increases memory savings through this action — so
> it saves memory at the cost of additional CPU overhead.
>
> If you want to address the increased overhead on ksmd, I think we could add a
> check for the shared zeropage in cmp_and_merge_page, and skip merging when a
> shared zeropage is detected.
>
>>>
>>> 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.
>>
>
> Actually, I have long thought about submitting a patch: add a new interface
> 'skip_huge_page' under KSM's sysfs, allowing users to choose not to split huge pages.

Just think out loud. Or just skip huge pages all the time unless memory pressure
is present. Basically treat KSM as a way of reducing memory pressure by merging
pages.

Best Regards,
Yan, Zi