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

[Nico Pache]

On Tue, Jul 21, 2026 at 8:02 AM David Hildenbrand (Arm)
<david@xxxxxxxxxx> wrote:
>
> On 7/20/26 17:28, Nico Pache wrote:
> > On Wed, Jul 15, 2026 at 3:30 AM David Hildenbrand (Arm)
> > <david@xxxxxxxxxx> wrote:
> >>
> >> On 7/15/26 06:05, Nico Pache wrote:
> >>>
> >>> This would be a good intermediate solution while allowing backward
> >>> compatibility.
> >>
> >> And an absolute horrible user-visible toggle :)
> >>
> >>>
> >>>
> >>> 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.
> >>>
> >>>
> >>> 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).
>
> Not sure. There could be anything else in the system triggering the split before
> KSM comes around.
>
> So v1 just cleanly separates them, independent who triggers the split.

Yes but now all VM_MERGEABLEs lose the underutilized shrinker
independent from weather KSM was the one who triggered it. So if you
split a folio from another path, and its VM_MERGEABLE we lose the
ability to reclaim these underutilized pages, despite not being from
KSM (where the behavior/"bug" lives).

>
> Why is this a problem?

its not a problem, but it now affects a larger scope than where the
problem originates. We could easily shrink the scope to only include
splits coming from KSM; then KSM would respect its sysctls, while not
regressing the shrinker's functionality on VM_MERGEABLE mappings.

Perhaps I'm not properly expressing the differences, or I'm not fully
understanding your concern with my V2 proposed solution.

Cheers,
-- Nico

>
> --
> Cheers,
>
> David
>