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

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

On 9/21/26 22:33, Joanne Koong wrote:
> On Mon, Sep 21, 2026 at 3:23 AM David Hildenbrand (Arm)
> <david@kernel.org> wrote:
>>
>> 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?
>>
> 
> Hi David,
> 
> I have a paragraph about this in the commit message of patch 2:
> 

Ah, okay, I only skimmed the cover letter so far.

-- 
Cheers,

David