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

[David Hildenbrand (Arm)]

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.

Why is this a problem?

-- 
Cheers,

David