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

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

On 9/17/26 00:44, 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.
> 
> Patch 1 makes thp_underused() folio-size aware. Today it only ever sees
> PMD-sized folios, so it assumes HPAGE_PMD_NR pages throughout. Patch 3
> breaks that assumption, so patch 1 generalizes it first. No functional
> changes are introduced.
> 
> Patch 2 keeps folios that can never be found underused off the deferred
> split queue, as suggested by Johannes. This changes/optimizes existing
> behavior. With the default khugepaged/max_ptes_none, PMD folios are queued
> today and then dropped again by the first scan without ever having been
> splittable. After this patch they are not queued at all.

I think we discussed queuing folios once the value changes and you would
actually be able to split some. Was there a good reason why that idea was dropped?

-- 
Cheers,

David