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 14:43, Usama Arif wrote:
> 
> 
> 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.

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