Re: [RFC PATCH v2 04/11] mm: khugepaged: add shmem mTHP collapse support

[Nico Pache <npache@redhat.com>]

On 6/10/26 6:44 AM, Lance Yang wrote:
> 
> On Wed, Jun 10, 2026 at 06:29:12PM +0800, Baolin Wang wrote:
> [...]
>> @@ -1512,8 +1517,12 @@ static enum scan_result mthp_collapse(struct mm_struct *mm,
>> 			enum scan_result ret;
>>
>> 			collapse_address = address + offset * PAGE_SIZE;
>> -			ret = collapse_huge_page(mm, collapse_address, referenced,
>> -						 unmapped, cc, order);
>> +			if (file)
>> +				ret = collapse_file(mm, collapse_address, file,
>> +						start + offset, cc, order);
>> +			else
>> +				ret = collapse_huge_page(mm, collapse_address,
>> +						referenced, unmapped, cc, order);
>>
>> 			switch (ret) {
>> 			/* Cases where we continue to next collapse candidate */
>> @@ -1521,6 +1530,7 @@ static enum scan_result mthp_collapse(struct mm_struct *mm,
>> 				collapsed += nr_ptes;
>> 				fallthrough;
>> 			case SCAN_PTE_MAPPED_HUGEPAGE:
> 
> Looks like SCAN_PTE_MAPPED_HUGEPAGE from collapse_file() get lost for
> the PMD-order case.

This is kinda my fault... I reused the enum PTE_MAPPED_HUGEPAGE (which was only
really used in file collapse) when reporting that a collapse attempts is smaller
or equal to the current order of the folio.

if (!is_pmd_order(order) && folio_order(folio) >= order) {

I will change that in my follow up to use its own (or a different enum).

> 
> Previously, collapse_file() returned it straight back to
> collapse_single_pmd(), so we would run try_collapse_pte_mapped_thp().
> 
> Now it hits mthp_collapse() fitst, and that case just goes to
> next_offset ...
> 
>> +			case SCAN_PAGE_COMPOUND:
>> 				goto next_offset;
>> 			/* Cases where lower orders might still succeed */
>> 			case SCAN_ALLOC_HUGE_PAGE_FAIL:
> [...]
> 
> Cheers, Lance
>