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

[Usama Arif <usama.arif@linux.dev>]

On Tue, 09 Jun 2026 10:07:20 -0400 Zi Yan <ziy@nvidia.com> wrote:

> On 9 Jun 2026, at 9:47, 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?
> >>
> >> 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.

I do agree with this. I questioned about if it even makes sense to split THP
with KSM in RFC (https://lore.kernel.org/all/20260510114001.600681-1-usama.arif@linux.dev/)


> 
> Best Regards,
> Yan, Zi
>