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