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

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

On Mon, 21 Sep 2026 00:20:14 +0800 Lance Yang <lance.yang@linux.dev> wrote:



+Kiryl who is working on khugepaged rework

> 
> 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
> >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 feel like the odd part of it is the 0 in the middle used by mTHP collapse,
not the 16 for checking zero-filled pages?

Kiryl, would your rework allow all values for mTHP collapse or would
it stil only allow HPAGE_PMD_NR = 1 and 0?

> Would a per-order value make more sense here?
> 

I feel like per-order might be too many knobs? What about a percentage
that might apply to all mTHP orders?

> An unset value could preserve the current behavior, while an explicit
> value could control both mTHP collapse and underused splitting. That

Ah are you proposing that mTHP collapse can then take all values from 
0 to mTHP number of pages?
I think one of the inital version of Nicos patches for mTHP collpase
allowed that (hopefully I am not misremembering). Nico, what was the
reason for only allowing 0 and max?

> would also give us a way to leave max_ptes_none as the legacy fallback
> instead of adding more meaning to it :)
> 
> Cheers, Lance

[...]