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

[David Hildenbrand (Arm)]

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.

-- 
Cheers,

David