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

[Nico Pache]

On Tue, Sep 15, 2026 at 1:52 PM David Hildenbrand (Arm)
<david@xxxxxxxxxx> wrote:
>
> On 8/25/26 19:34, David Hildenbrand (Arm) wrote:
> > On 8/5/26 18:27, Nico Pache wrote:
> >> On Thu, Jul 30, 2026 at 2:34 AM David Hildenbrand (Arm)
> >> <david@xxxxxxxxxx> wrote:
> >>>
> >>>
> >>> 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).
> >
> > I think we should really just stop two mechanisms to compete entirely: if A is
> > active for a region, B is disabled.
> >
> > Not trying to follow "who split what" and operate based on that.
> >
>
> I took another look and there is just no perfect solution.
>
>
> Option A: don't let mechanisms interfere - if KSM is enabled, don't remap to the
>           shared zeropage
>
> Positive: same KSM behavior even if some other mechanism decides to split.
> Negative: reclaim cannot free up these pages immediately (waits for KSM), and
>           having the deferred shrinker split to then not reclaim any actual
>           memory is stupid.
>
> Given that the second KSM run would already deduplicate these pages, I am not
> sure how much reclaim actually matters.
>
> But taming the deferred shrinker is a bit complicated (no VMA available). In
> configurations where the deferred shrinker will never trigger a split that's not
> a problem, but with lower max_ptes_none it would be possible to trigger.
>
>
> Option B: don't let KSM splits remap to the shared zeropage
>
> Positive: Fix isolated to the actual problematic part we observed.
> Negative: Different KSM behavior depending on who split a THP first.
>
>
> Assume KSM scanned the range first, and then the deferred shrinker split many
> THP in that area and creates shared zeropage. On the next KSM run, we'd have a
> very similar behavior. If KSM runs first, you either get zeropages or
> deduplication to a zero-filled page.
>
>
> I would not go down a path where we would let KSM skip THPs entirely.
>
> Maybe one could teach KSM about "the deferred shrinker is active, don't split a
> THP if we are to deduplciate the shared zeropage"? But then, whether the
> deferred shrinker will actually split depends on the max_ptes_non toggle.
>
>
> Gahhh so complicated.

haha very much so!

This might be the correct solution below, similar to your logic above....

static void cmp_and_merge_page(struct page *page, struct ksm_rmap_item
*rmap_item)
{
...
checksum = calc_checksum(
              if (rmap_item->oldchecksum != checksum)
                  rmap_item->oldchecksum = checksum;
                  return;
              }
+               if (folio_test_large(folio) && split_underused_thp &&
+                   checksum == zero_checksum &&
+                   pages_identical(page, ZERO_PAGE(0)))
+                       return;
+

Don't let KSM split a THP if it's a zero page (unless the underused
shrinker is inactive)

We also do patch 3 of this series, which disables zero-page remapping
if the underused shrinker is disabled.

With this I believe all edge cases and feature interactions are now exclusive.

I will retest. Let me know what you think, and if you agree, I can post it.

Thanks for taking the time to look back at this :) Sorry I've been a
bit MIA too, I've been focused on some downstream issues. I've been
meaning to review/reply to the high volume of khugepaged patches
recently.

-- Nico



>
> --
> Cheers,
>
> David
>