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

[Lorenzo Stoakes <ljs@kernel.org>]

On Tue, Jun 09, 2026 at 09:49:47PM +0800, xu.xin16@zte.com.cn wrote:
> > > >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 :)
> >
> > Yeah maybe I didnt properly explain that :p
> >
> > After some thought I still think the alternative approach i mentioned
> > in the RFC may be better.
> >
> > ie) prevent the zero-page merging that results from KSM splitting a
> > folio. The check we add here is more general and will skip this
> > zero-page merging with all MERGEABLE mappings, not just those causing
> > the issue (the KSM splitting). The result is that even migrations, etc
> > that are also MERGEABLE will be skipped needlessly.
> >
> > If we use this approach we also don't need the first patch of the series.
>
> Yeah, That's also what I want to suggest.

I guess I'll hold off on review until the new version is posted then.

This feels like something we should have worked out in the RFC though?

Thanks, Lorenzo