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

["David Hildenbrand (Arm)" <david@kernel.org>]

On 7/29/26 15:43, Usama Arif wrote:
> 
> 
> On 29/07/2026 13:36, David Hildenbrand (Arm) wrote:
>> On 7/8/26 11:58, Usama Arif wrote:
>>>
>>>
>>>
>>> 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?

It's definitely better but I think it's also not an ultimate solution to the
overall problem I'm afraid. As we increase COSTLY_ORDER (what people are already
talking about) the behavior would change, and that's not good.

-- 
Cheers,

David