On Wed, Jun 10, 2026 at 06:29:15PM +0800, Baolin Wang wrote:
[...]
>@@ -2843,6 +2853,11 @@ static enum scan_result collapse_scan_file(struct 
>mm_struct *mm,
>               goto out;
>       }
> 
>+      if (bitmap_empty(cc->mthp_present_ptes, MAX_PTRS_PER_PTE)) {
>+              result = SCAN_FAIL;
>+              goto out;
>+      }

This check seems to jump the gun a bit for MADV_COLLAPSE ...

shmem swap entries only bump "swap" during the scan in
collapse_scan_file():

                if (xa_is_value(folio)) {
                        swap += 1 << xas_get_order(&xas);
                        if (swap > max_ptes_swap) {
                                result = SCAN_EXCEED_SWAP_PTE;
                                count_vm_event(THP_SCAN_EXCEED_SWAP_PTE);
                                break;
                        }
                        continue;
                }

Holes don't set the bitmap either. They just show up later through the
"present" check:

        if (present < HPAGE_PMD_NR - max_ptes_none) {
                result = SCAN_EXCEED_NONE_PTE;
                count_vm_event(THP_SCAN_EXCEED_NONE_PTE);
                count_mthp_stat(HPAGE_PMD_ORDER,
                                MTHP_STAT_COLLAPSE_EXCEED_NONE);
                goto out;
        }

For MADV_COLLAPSE, both max_ptes_none and max_ptes_swap are HPAGE_PMD_NR,
so those checks still let this through.

So now we bail with SCAN_FAIL before collapse_file() ever sees the case,
even though that code still handles both: swap via shmem_get_folio(),
holes via nr_none.

Am I reading that right? If so, looks like a regression ...

>+
>       result = mthp_collapse(mm, file, start, addr, 0, 0, cc, enabled_orders);
>       if (result == SCAN_SUCCEED && !cc->is_khugepaged) {
>               /* If MADV_COLLAPSE, adjust result to call 
> collapse_pte_mapped_thp(). */
>-- 
>2.47.3
>

Cheers, Lance

Reply via email to