Re: [PATCH v1 2/2] mm/memory: add anonymous mTHP folios to deferred split list

On Tue, Aug 04, 2026 at 04:11:02PM +0200, David Hildenbrand (Arm) wrote:
> On 8/4/26 16:03, Johannes Weiner wrote:
> > On Tue, Aug 04, 2026 at 10:03:14AM +0800, Barry Song wrote:
> >> On Tue, Aug 4, 2026 at 8:48 AM Johannes Weiner <[email protected]> wrote:
> >>>
> >> [...]
> >>>
> >>> I am very confused. Did you not see my proposal above?
> >>>
> >>> Why not this?
> >>
> >> Hi Johannes,
> >>
> >> For arm64, if the base page size is 64KB, a PMD would be 512MB,
> >> and PMD-1 would be 256MB. Usama mentioned 2MB, which is just
> >> order-5, not PMD-1 on arm64.
> >>
> >> BTW, I assume khugepaged_max_ptes_none is intended for collapse,
> >> not splitting. I am a bit concerned that reusing it for this
> >> purpose would be quite disruptive.
> > 
> > It already is:
> > 
> > static bool thp_underused(struct folio *folio)
> > {
> > 	int num_zero_pages = 0, num_filled_pages = 0;
> > 	int i;
> > 
> > 	if (khugepaged_max_ptes_none == HPAGE_PMD_NR - 1)
> > 		return false;
> > 
> > 	if (folio_contain_hwpoisoned_page(folio))
> > 		return false;
> > 
> > 	for (i = 0; i < folio_nr_pages(folio); i++) {
> > 		if (pages_identical(folio_page(folio, i), ZERO_PAGE(0))) {
> > 			if (++num_zero_pages > khugepaged_max_ptes_none)
> > 				return true;
> > 		} else {
> > 			/*
> > 			 * Another path for early exit once the number
> > 			 * of non-zero filled pages exceeds threshold.
> > 			 */
> > 			if (++num_filled_pages >= HPAGE_PMD_NR - khugepaged_max_ptes_none)
> > 				return false;
> > 		}
> > 	}
> > 	return false;
> > }
> > 
> > That's ABI and setups are relying on it.
> > 
> > All I'm proposing is to only queue pages that the shrinker would
> > actually split under currently existing rules. That's a mostly
> > transparent optimization, not a new policy.
> 
> I yet have to reply to some stuff here (sorry, it's a mess :( ), but one thing
> that annoyed me right from the start is that we have:
> 
> static bool split_underused_thp = true;
> 
> But the default khugepaged settings actually don't result in any splits.
> 
> I think it would already be a big improvement to not default to adding all pages
> in default setups.
> 
> When we last discussed changing that, one concern raised in the past was that
> changing the khugepaged setting later would then not be able to reclaim pages
> allocated up to that point.

Agree, that could be unexpected.

> When someone actually changes khugepaged settings such that the underused
> shrinker would get active, could we walk the LRU and add all eligible anon THPs
> to the underused shrinker? We could remember "already scanned for underused" per
> THP, but maybe we could avoid that initially.

Recovery like that makes sense to me. I don't think we have to be
extremely performant either, that should be a rare setting change.

Would it make sense to use khugepaged_scan.mm_head? That could be more
targeted when policy == madvise, easier to skip over shmem VMAs etc.