Re: [RFC v2 9/9] khugepaged: skip collapsing mTHP to smaller orders

[Ryan Roberts <ryan.roberts@arm.com>]

On 11/02/2025 00:30, Nico Pache wrote:
> khugepaged may try to collapse a mTHP to a smaller mTHP, resulting in
> some pages being unmapped. Skip these cases until we have a way to check
> if its ok to collapse to a smaller mTHP size (like in the case of a
> partially mapped folio).
> 
> This patch is inspired by Dev Jain's work on khugepaged mTHP support [1].
> 
> [1] https://lore.kernel.org/lkml/20241216165105.56185-11-dev.jain@arm.com/
> 
> Signed-off-by: Nico Pache <npache@redhat.com>
> ---
>  mm/khugepaged.c | 5 +++++
>  1 file changed, 5 insertions(+)
> 
> diff --git a/mm/khugepaged.c b/mm/khugepaged.c
> index e2ba18e57064..fc30698b8e6e 100644
> --- a/mm/khugepaged.c
> +++ b/mm/khugepaged.c
> @@ -622,6 +622,11 @@ static int __collapse_huge_page_isolate(struct vm_area_struct *vma,
>  		folio = page_folio(page);
>  		VM_BUG_ON_FOLIO(!folio_test_anon(folio), folio);
>  
> +		if (order != HPAGE_PMD_ORDER && folio_order(folio) >= order) {
> +			result = SCAN_PTE_MAPPED_HUGEPAGE;
> +			goto out;
> +		}

One of the key areas where we want to benefit from khugepaged collapsing to mTHP
is when a COW event happens. If the original folio was large, then it becomes
partially mapped due to COW and we want to collapse it again. I think this will
prevent that?

I made some fairly detailed suggestions for what I think is the right approach
in the context of Dev's series. It would be good to get your thoughts on that:

https://lore.kernel.org/lkml/aa647830-cf55-48f0-98c2-8230796e35b3@arm.com/

Thanks,
Ryan

> +
>  		/* See khugepaged_scan_pmd(). */
>  		if (folio_likely_mapped_shared(folio)) {
>  			++shared;