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

[xu.xin16]

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