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

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

On 9/23/26 02:44, Joanne Koong wrote:
> On Mon, Sep 21, 2026 at 3:12 AM David Hildenbrand (Arm)
> <david@kernel.org> wrote:
>>
>> On 9/20/26 18:20, Lance Yang wrote:
>>>
>>
>> "David objected to the scaling", not quite. The tricky bit is the scaling when
>> collapsing (creep).
>>
>> When freeing, I'd assume scaling should be alright.
> 
> Ah, apologies for misinterpreting your comment.
> 
>>
>>>
>>> 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 very much prefer scaling over using absolute numbers as proposed here.
>>
> 
> With scaling, I don't see a way of avoiding having to queue every
> anonymous folio of order >=2 to the deferred split list at fault time
> in the non-default max_ptes_none case, since any folio can now
> potentially qualify as underused. 

Exactly.

I was primarily arguing that I don't want this overhead for the majority of
Linux installations out there that ship with

$ cat /sys/kernel/mm/transparent_hugepage/khugepaged/max_ptes_none
511

IOW: we add them (PMD THP folios today!) to the deferred list for
uuderused-scanning but never actually scan them because of:

	if (khugepaged_max_ptes_none == HPAGE_PMD_NR - 1)
		return false;

Now, what you are saying is we might want less overhead for installations that
modify max_ptes_none, like Meta's fleet. See below.

> This drew some objections in v1,
> particularly for the Android small folios case. I read that as ruling
> out scaling. The objections were a) the list_lru lock contention and

It was the "deferred shrinker list and lock" contention, yes.

> b) the limited upside vs cost of splitting small folios.
> 
> For a), I don't think there were any hard numbers showing this is a
> problem. If it would be helpful to have some benchmark numbers, I'm
> happy to run a synthetic one (patch 3 applied (which adds anon mTHP
> folios to the deferred split list), only order-2 enabled,
> max_ptes_none set low enough, all threads in one cgroup on one node so
> they contend on the same lock, each thread faulting in a large private
> anonymous mapping). I'm happy to run something else if anyone has a
> workload they would trust more. Johannes also mentioned batching as a
> mitigation. If the contention does turn out to be an issue, I'm happy
> to prototype that and measure it too.

Right, I raised that. Johannes thinks it could be fixed with batching. I was
concerned that it would become rather ugly. We'd have to see how that could look.

> 
> For b), v1 unconditionally queued every folio of order >= 2. v2 added
> an optimization patch for skipping queueing entirely if max_ptes_none
> is at its default value, which would also carry over if we went with
> scaling. So I think with that patch added, for the objection to b), it
> depends on what max_ptes_none Android actually runs. At the default
> max_ptes_none, nothing would be queued at all, so a config that sees
> no benefit from splitting small folios would pay nothing for it.

I would assume everybody except some special users that fine-tune underused
shrinker run with the default. I did some digging in the past regarding public
documentation about how to set the parameter, and most of them just defaulted to
511.

I would be surprised if Android even knows about this parameter ;)

> 
> Does that make scaling acceptable to you and Barry? If so, I'd prefer
> that as well because if/when intermediary values are supported for
> mTHP collapse, that support would have to be proportional, and it'd be
> easier to reconcile the two with split also scaled. If not, then what
> would be the suggestion for where to take v3?
My opinion is (open for discussion :) ) that scaling is likely the better
approach. With the following notes:

(1) If we want to enable mTHP collapse with scaling as well, this needs very
good documentation and also another thought on how to work around the problem of
creep (e.g., refusing to collapse if creep would be possible according to the
max_ptes_non setting and warning).

(2) Systems where the underused shrinker is effectively inactive should not add
folios to the deferred list. Including PMD THPs, which we unconditionally add today.

(3) If we want to exclude certain small folio sizes from the underused shrinker
(e.g., order-2? order-3?) it might be better to just hard-code that in the
kernel instead of giving the admin a choice it cannot possibly make easily.


-- 
Cheers,

David