Re: [PATCH v1 2/2] mm/memory: add anonymous mTHP folios to deferred split list

[Usama Arif <usama.arif@linux.dev>]

On 08/07/2026 08:56, David Hildenbrand (Arm) wrote:
> On 7/7/26 22:17, Joanne Koong wrote:
>> Unlike for PMD-sized folios, an anonymous mTHP folio doesn't get added
>> to the deferred split list at fault or collapse time. As a result, a
>> fully mapped mTHP folio that is mostly zero-filled doesn't get split by
>> the deferred split shrinker when the system is under memory pressure.
>>
>> Add anonymous mTHP folios to the deferred split list so that if there's
>> memory pressure, a zero-filled mTHP can be split with its zero pages
>> remapped to the shared zero page and then reclaimed.
>>
>> To minimize overhead on the common order-0 fault path, the
>> deferred_split_folio() call is guarded by an inline folio_test_large()
>> check.
>>
>> Suggested-by: Usama Arif <usama.arif@linux.dev>
>> Signed-off-by: Joanne Koong <joannelkoong@gmail.com>
>> ---
>>  mm/memory.c | 2 ++
>>  1 file changed, 2 insertions(+)
>>
>> diff --git a/mm/memory.c b/mm/memory.c
>> index 6637c5b13c9b..441d918e3dc0 100644
>> --- a/mm/memory.c
>> +++ b/mm/memory.c
>> @@ -5259,6 +5259,8 @@ void map_anon_folio_pte_nopf(struct folio *folio, pte_t *pte,
>>  	folio_add_lru_vma(folio, vma);
>>  	set_ptes(vma->vm_mm, addr, pte, entry, nr_pages);
>>  	update_mmu_cache_range(NULL, vma, addr, pte, nr_pages);
>> +	if (folio_test_large(folio))
>> +		deferred_split_folio(folio, false);
>>  }
>>  
>>  static void map_anon_folio_pte_pf(struct folio *folio, pte_t *pte,
> 
> I had a session [1] at LSF/MM about having essentially all large anon folios
> part of the the deferred split queue.
> 
> (1) I don't think this scales.
> 

What if we only add the mTHPs for which the policy is set to always.

I think it doesn't scale if someone sets all orders to always, but if you only
set the 2M mTHP sysfs to always, it should be the same as what we have today
for PMD order?

The main motivation for this series is to try and bring the performance for
ARM on par with x86. One of the differences is TLB misses. I imagine the lower
churn in kernel by using larger page sizes will help as well. But we will
run into OOMs without the shrinker.
 

> (2) I suspect the shrinker should make smarter decisions of what to scan/reclaim
> first.

Yes definitely agree!

Alexandre is looking into this as well.

> 
> I think this needs more proper thought.
> 
> [1]
> https://docs.google.com/presentation/d/1RfKWCY1AMVns-WLn-QdAWbI2a-rA7fbFyh7XD1Wn5BY/edit?usp=sharing
>