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

[Nico Pache]

On Wed, Jul 15, 2026 at 3:30 AM David Hildenbrand (Arm)
<david@xxxxxxxxxx> wrote:
>
> On 7/15/26 06:05, Nico Pache wrote:
> > On Tue, Jun 9, 2026 at 11:27 AM Usama Arif <usama.arif@xxxxxxxxx> wrote:
> >>
> >> On Tue, 09 Jun 2026 10:07:20 -0400 Zi Yan <ziy@xxxxxxxxxx> wrote:
> >>
> >>>
> >
> > This would be a good intermediate solution while allowing backward
> > compatibility.
>
> And an absolute horrible user-visible toggle :)
>
> >
> >>>
> >>> 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.
> >
> > Hmm interesting. We should decide on future changes before committing
> > to one direction; however, i think the immediate solution would be
> > what I currently have prepped for v2.
> >
> > My v2 follows my RFC alternative approach: skip zeropage remapping if
> > the split comes from KSM. It also contains the patch (3) from this
> > version, which skips zeropage remapping if the shrinker is disabled.
> >
> >>
> >> 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@xxxxxxxxx/)
> >
> > This is indeed a good question but I don't know the right solution.
> >
> > Perhaps we can discuss it here.
> >
> > So far here are the potential solutions:
> > a) skip zeropage remapping if the split comes from KSM
> > b) skip zeropage remapping completely if the shrinker is disabled
> > c) Disable KSM THP splitting completely
> > d) add a skip_huge_page sysfs toggle
> > e) only scan THPs when memory pressure is present
> >
> > (a)+(b) would be my V2 which I can send out whenever.
> >
> > (c) is the nuclear option, but perhaps KSM for THP is rather
> > inefficient and pointless
> >
> > (d) could be used with (a) and (b) and allows more flexibility than (c)
> >
> > (e) is a more dynamic approach, and could be combined with (b) and (d)
> >
> > Let me know what you think :)
>
> Where does the current patch set fall into and what's the problem with it?

this series (v1) would be "dont scan VM_MERGEABLE entries when KSM is running"

It stops all VM_MEREABLE entries from being candidates, while the V2 I
would like to propose goes back to my RFC's alternative solution
a ) "skip zeropage remapping if the split comes from KSM"

I think (a) is better than V1 as it doesnt indiscriminately target all
VM_MERGEABLE mapping but rather those that are triggering the issue
(the split).

Cheers,
-- Nico

>
> --
> Cheers,
>
> David
>