Re: [PATCH v3 3/3] mm/khugepaged: release contended mmap read lock after scanning enough VMAs

[Lorenzo Stoakes (ARM)]

On Tue, Nov 10, 2026 at 05:19:13PM +0000, Lorenzo Stoakes (ARM) wrote:
> khugepaged walks an mm's VMAs under the mmap read lock in
> collapse_scan_mm_slot(), checking for ineligible VMAs first, and skipping
> them if encountered.
>
> It charges cc->progress 1 page against the /sys/.../pages_to_scan budget
> when these are encountered, however only checking this budget once an
> eligible PMD-spanning VMA is encountered.
>
> It can therefore hold the mmap read lock for a long time if there are a
> large number of ineligible VMAs present in an mm, over which time no mmap
> write locks (and thus no VMA write locks) can be acquired.
>
> Address this by checking whether the mmap lock is contended after 1-10
> ms (depending on CONFIG_HZ), i.e. the granularity of jiffies. This is a
> long time for a lock to be held, so is a reasonable compromise for
> determining when best to do this.

Oops I left this in from the previous approach :)

Replace with:

	Address this by checking whether the mmap lock is contended after 1024
	VMAs scanned. This was measured to take around ~100 us on a fast
	machine, and given VMA eligibility checking is a light operation, it is
	likely this will remain at the same order of magnitude for slower
	machines.

	This therefore establishes a reasonable upper bound on how long a
	contended mmap lock is held.

Thanks! :)

--
Cheers, Lorenzo