Re: [PATCH v2 0/3] mm: split underused anonymous mTHP folios

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

On 9/20/26 18:20, Lance Yang wrote:
> 
> On Wed, Sep 16, 2026 at 03:44:34PM -0700, Joanne Koong wrote:
>> PMD-sized THPs that are mostly zero-filled are reclaimed under memory
>> pressure by the deferred split shrinker, but this is not done for mTHP
>> folios. At Meta we would like to deploy 2M THP=always on arm64 with 64k
>> base pages, as 2M provides the contpte benefits while the PMD size there
>> (512M) is too big to use. However, 2M THP=always causes memory regressions
>> unless the unused portions of those folios can be broken down and
>> reclaimed.
>>
>> v1 did two things. It scaled khugepaged_max_ptes_none down per folio order and
>> it queued every anonymous mTHP folio. David objected to the scaling since

"David objected to the scaling", not quite. The tricky bit is the scaling when
collapsing (creep).

When freeing, I'd assume scaling should be alright.

>> collapse had already rejected proportional scaling as either letting the memory
>> footprint creep or being confusing to reason about. David and Barry separately
>> objected to the queuing, which adds list_lru lock contention on every anonymous
>> fault, and hurts lower-order use cases such as Android's order-2-only
>> configuration. Johannes suggested keeping khugepaged_max_ptes_none absolute and
>> simply not queuing folios that could never exceed it, which addresses both.
>>
>> Read as an absolute count, khugepaged_max_ptes_none also implies the
>> smallest folio that takes part in underused splitting. A 2M folio on 64k
>> base pages is 32 pages, so the knob has to be set below 32 for those to
>> be queued at all, and any folio with no more pages than the value stays off
>> the queue entirely.
> 
> Em ... I'm not sure max_ptes_none should also become the mTHP underused
> threshold ...
> 
> Say we're on arm64 with 64K pages and set it to 16. Khugepaged PMD
> collapse uses 16, while mTHP collapse turns the same value into 0. With
> this series, an order-5 (2 MiB) mTHP enters the deferred split queue
> because it has 32 pages, and is considered underused once more than 16
> pages are zero-filled. So the same knob means 16, 0, and 16 depending on
> where it is used ... That's a bit odd ... no?

I very much prefer scaling over using absolute numbers as proposed here.

> 
> Would a per-order value make more sense here?
> 
> An unset value could preserve the current behavior, while an explicit
> value could control both mTHP collapse and underused splitting. That
> would also give us a way to leave max_ptes_none as the legacy fallback
> instead of adding more meaning to it :)

The problem is that: we don't want any new toggles unless unavoidable.

-- 
Cheers,

David