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

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

On 29/07/2026 13:36, David Hildenbrand (Arm) wrote:
> On 7/8/26 11:58, Usama Arif wrote:
>>
>>
>> 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.
> 
> That doesn't really help lock contention. And the lock contention is indeed a
> thing, as we now also want to enable the LRU cache for smaller large folios,
> which improves performance:
> 
> https://lore.kernel.org/r/20260709081536.82768-1-baohua@kernel.org
> 
>>
>> 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?
> 
> I don't see a problem with large large folios, only with small large folios :)
> 
>>
>> 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.
> 
> Can you elaborate how this change helps here? I assume you want to enable mTHP
> in production. Which sizes? large large ones? :)
> 

One of the differences in our production between x86 and ARM hosts which we think
should perform at a similar level (but currently aren't) is TLB misses.

On x86, we have 2M THP set to always.
On ARM, we have base page size of 64K. 2M mTHPs should help bridge the gap due to
TLB coalescing. We can't really set 2M mTHP to always as without the mTHP shrinker
we will end up with severe memory pressure and a significant increase in OOMs.

We don't plan to enable other mTHP sizes on ARM, only 2M.

The series by Barry is for folios above costly order, so won't impact this.

David, Joanne, Johannes: what do you think about only adding folios that are larger
than COSTLY_ORDER to deferred split list?