Re: [PATCH v2 2/3] mm/khugepaged: scan mm's more efficiently under mmap_lock contention
From: Baolin Wang
Date: Fri Nov 06 2026 - 04:38:45 EST
On 11/6/26 4:57 AM, Lorenzo Stoakes (ARM) wrote:
khugepaged scans VMAs in collapse_scan_mm_slot() in the same mm until it is
about to be torn down, prctl(PR_SET_THP_DISABLE) disables THP for it,
mm->mmap_lock contention occurs, or all its VMAs have been scanned.
When lock contention causes the function to bail out, khugepaged doesn't
keep track of where it left off, so when the mm is next scanned, it starts
from address 0 again.
If there's a lot of mmap_lock contention this can significantly slow down
collapse later in the mm, since the /sys/.../pages_to_scan budget can run
out before the end of the mm is reached.
The budget is incremented (as tracked in cc->progress) at a rate of 1 page
per ineligible VMA, but the budget is only checked once eligible VMAs are
encountered.
Then, it only takes the combined total of ineligible VMAs and eligible but
non-collapsible pages to exceed the /sys/.../pages_to_scan budget for the
rest of the mm to be skipped.
For a system with 4 KiB page size and default sysctl settings this only
requires 4096 ineligible VMAs/uncollapsible pages to be skipped before this
happens.
Resolve the issue by simply tracking the last examined address in the
khugepaged_mm_slot object, so when the mm is resumed, the scan starts from
where it left off.
Additionally, skip to the next candidate if a VMA cannot be collapsed.
This issue was noticed during some work in which an mm was instantiated
with a large number of small VMAs under significant mmap_lock contention,
during which collapse was observed to take 10.8s. With this patch applied
it took 3.6s to collapse the same mm.
Nice results!
Also, while here, update a couple VM_BUG_ON()'s to VM_WARN_ON_ONCE()'s.
This patch is also a prerequisite for the next patch in the series.
Reviewed-by: David Hildenbrand (Arm) <david@xxxxxxxxxx>
Reviewed-by: Lance Yang <lance.yang@xxxxxxxxx>
Signed-off-by: Lorenzo Stoakes (ARM) <ljs@xxxxxxxxxx>
---
Make sense to me.
Reviewed-by: Baolin Wang <baolin.wang@xxxxxxxxxxxxxxxxx>