Re: [PATCH v1 0/2] mm: split underused anonymous mTHP folios

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

On 7/8/26 20:19, Joanne Koong wrote:
> On Wed, Jul 8, 2026 at 12:47 AM David Hildenbrand (Arm)
> <david@kernel.org> wrote:
>>
>> On 7/7/26 22:17, 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 ARM (with 64k base pages), as 2M
>>> provides contpte benefits and 512M is too big. However, 2M THP=always will
>>> result in a memory regression unless the extra unused portions of THPs can be
>>> broken down and reclaimed.
>>>
>>> This series has two patches:
>>> Patch 1 - makes thp_underused() work for non-PMD-sized folios by scaling
>>> khugepaged_max_ptes_none proportionally to the folio size and using that
>>> as the threshold for how many zero-filled pages a folio can contain before
>>> it's considered underused.
>> Did you look at the khugepaged side, and how we handle it there?
> 
> I'm not sure if I'm interpreting your suggestion correctly - is your
> suggestion about using the khugepaged mTHP collapse threshold in
> collapse_max_ptes_none()? I had looked at Nico's patchset in [1] and
> my understanding of it was that the mTHP collapse threshold currently
> only supports values of 0 and HPAGE_PMD_NR - 1. The patch 1 changes
> use khugepaged_max_ptes_none's value as a proportional per-order
> threshold for mTHP because 0 and HPAGE_PMD_NR - 1 are too extreme for
> our use case where we're trying to find a middle ground that keeps
> mostly-populated 2M folios whole but splits mostly zero-filled ones.
> 
> Is that what you had in mind or were you pointing at something else on
> the khugepaged side?

Yes, essentially that khugepaged does not apply the scaling because we discussed
it back and forth and it either results slowly consuming more memory than
intended (creep), or ends up being completely confusing for users.

So khugepaged will currently only collapse mTHP if it can either not waste any
memory, or is told to waste as much memory as it wants.

Adding scaling here when we explicitly rejected it in the collapse path looked
odd at first.

I assume your point would be that just mTHP over-allocation (not due to
khugepaged) could make scaling here a good choice, correct?

-- 
Cheers,

David