Re: [RFC] mm: restrict zero-page remapping to underused THP splits

[Lance Yang]

On Mon, May 18, 2026 at 10:24:26AM +0200, David Hildenbrand (Arm) wrote:
>On 5/14/26 10:11, Lance Yang wrote:
>> 
>> On Tue, May 12, 2026 at 09:02:38PM +0200, David Hildenbrand (Arm) wrote:
>>> On 5/12/26 20:36, Nico Pache wrote:
>>>> On Tue, May 12, 2026 at 1:05 AM David Hildenbrand (Arm)
>>>> <david@xxxxxxxxxx> wrote:
>>>>
>>>> I meant before b1f202060afe ("mm: remap unused subpages to shared
>>>> zeropage when splitting isolated thp"). Sorry, I should have been more
>>>> specific.
>>>>
>>>> As in before the underutilized shrinker (and commit b1f202060afe), we
>>>> had the exact problem you describe above and no way to handle it.
>>>> Correct?
>>>
>>> Right. That's why the underused shrinker was added, to directly free pages that
>>> have been over-allocated with a THP, but are actually never "used" (remain zero).
>>>
>>>>
>>>> I guess at reclaim THPs would be split and we would swap out a zero filled page?
>>> We don't necessarily split during swapout, we try to swap out the THP if
>>> supported. But yes, that can happen.
>>>
>>> I'm more thinking about other reasons to split a THP (e.g., migration, partial
>>> MADV_PAGEOUT/MADV_COLD/MADV_FREE), where the behavior would be changed.
>> 
>> Yeah. Today any successful anon split gets TTU_USE_SHARED_ZEROPAGE. Would
>> it be better to make KSM opt out, so other split paths keep the behavior
>> they have today?
>> 
>> That way we do not have to worry about changing anything else at the
>> same time :D
>
>This is (1) here:
>
>https://lore.kernel.org/all/04ea0e68-de56-49c4-8c9f-1734139d5e7f@xxxxxxxxxx/
>
>There will still be interaction between both mechanisms. So I'd prefer that in
>VM_MERGEABLE sections with KSM enabled, only KSM would take care of deduplicating.

Cool. I'd go with that approach as well. It should avoid unexpected
interaction between the two :)

That should keep VM_MERGEABLE VMAs under KSM's control, while leaving
the other split paths unchanged for now.

Cheers, Lance