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

[Kiryl Shutsemau <kas@kernel.org>]

On Mon, Sep 21, 2026 at 03:08:49AM -0700, Usama Arif wrote:
> 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?

I didn't change the policy here.

What I considered doing it allow proportional treatment of max_ptes_none
for terminal mTHP size -- when there's no larger mTHP or PMD THP allowed
on the system. It can be helpful for 2M mTHPs on ARM machines with 64K
base page size and 512M PMDs.

-- 
  Kiryl Shutsemau / Kirill A. Shutemov