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

On Thu, Jul 30, 2026 at 2:34 AM David Hildenbrand (Arm)
<[email protected]> wrote:
>
> On 7/29/26 18:54, Nico Pache wrote:
> > On Tue, Jul 21, 2026 at 8:02 AM David Hildenbrand (Arm)
> > <[email protected]> wrote:
> >>
> >> On 7/20/26 17:28, Nico Pache wrote:
> >>> On Wed, Jul 15, 2026 at 3:30 AM David Hildenbrand (Arm)
> >>> <[email protected]> wrote:
> >>>
> >>> 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.
>
> Because KSM takes care of it?

KSM only takes care of it in the case of 'use_zero_pages' being set.
If we stop KSM splits from reclaiming, we regain the intended sysctl
behavior; otherwise, KSM splits and reclaims indiscriminately. The
secondary effect is that if we don't have this toggle set, the split
would still reclaim these pages. KSM then has to process those pages
(despite them already being freed), wasting cycles.

Your proposed solution works too, I just think its a more aggressive
approach (stop all VM_MERGEABLEs from split-reclaiming, not just those
that are currently being operated on by KSM).

-- Nico

>
> What am I missing?
>
> --
> Cheers,
>
> David
>