Re: [PATCH v3 3/3] mm: add anonymous mTHP folios to the deferred split list

[Kiryl Shutsemau <kas@kernel.org>]

On Fri, Oct 23, 2026 at 04:00:06PM -0700, Joanne Koong wrote:
> Unlike for PMD-sized folios, an anonymous mTHP folio doesn't get added
> to the deferred split list at fault or collapse time. As a result, a
> fully mapped mTHP folio that is mostly zero-filled doesn't get split by
> the deferred split shrinker when the system is under memory pressure.
> 
> At Meta we would like to deploy 2M THP=always on arm64 with 64k base
> pages, as 2M gives the contpte benefits while the PMD size (512M) is too
> big to use. Without underused splitting this causes memory regressions,
> as the unused parts of those folios can never be broken down and
> reclaimed.
> 
> Add anonymous mTHP folios to the deferred split list from
> map_anon_folio_pte_nopf(), mirroring what map_anon_folio_pmd_nopf()
> already does for PMD-sized folios. This covers both the fault path and
> the khugepaged mTHP collapse path. If there is memory pressure, a
> zero-filled mTHP can then be split with its zero pages remapped to the
> shared zero page and reclaimed.
> 
> Only queue mTHP folios of at least 2M for underused splitting. With
> thp_underused() scaling khugepaged/max_ptes_none to the folio size, any
> folio of order 2 or above could in principle be underused, but for small
> folios it is unlikely to be worth it. An order-2 folio on 4k base pages
> can free at most four pages and on systems that only enable small mTHP
> sizes (eg Android's order-2-only configuration) zero-filled subpages
> tend to be few and short-lived.
> 
> The minimum is hard-coded rather than a knob, since admins have no good
> way of choosing it, and is a size rather than an order since what a
> split recovers depend on the folio's size in bytes, and the same order

s/depend/depends/

> means very different sizes across different base page sizes. It can be
> lowered later if data shows smaller sizes are worth it. PMD-sized folios
> are exempt from the minimum in order to maintain backwards compatibility
> since on some architectures (s390, with a 1M PMD) the PMD size can be
> below 2M.

...

> diff --git a/mm/memory.c b/mm/memory.c
> index 976cd03954e3..0622425649c6 100644
> --- a/mm/memory.c
> +++ b/mm/memory.c
> @@ -5501,6 +5501,8 @@ void map_anon_folio_pte_nopf(struct folio *folio, pte_t *pte,
>  	folio_add_lru_vma(folio, vma);
>  	set_ptes(vma->vm_mm, addr, pte, entry, nr_pages);
>  	update_mmu_cache_range(NULL, vma, addr, pte, nr_pages);
> +	if (folio_test_large(folio))
> +		deferred_split_folio(folio, false);
>  }

With this, thp_underused_split_page starts counting mTHP splits.
thp_split_page and thp_deferred_split_page count PMD-sized folios only,
and mTHPs get per-order stats instead. thp_underused_split_page can now
be larger than thp_split_page, and the per-order split counter does not
tell underused splits from the rest.

Should thp_underused_split_page stay PMD-only, with a per-order counter
for underused splits?

This is messy. I am not sure excluding non-PMD splits from the counter
is the right call, but it seems to be the most consistent solution.

-- 
  Kiryl Shutsemau / Kirill A. Shutemov