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

[Baolin Wang <baolin.wang@linux.alibaba.com>]

On 6/12/26 6:22 PM, Nico Pache wrote:
> 
> 
> 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).

Maybe use SCAN_PAGE_COMPOUND? Anyway, I’ve already fixed the issue Lance 
raised locally.