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

["Lorenzo Stoakes (ARM)" <ljs@kernel.org>]

On Thu, Nov 12, 2026 at 10:26:46AM +0100, David Hildenbrand (Arm) wrote:
> On 11/10/26 20:09, Lorenzo Stoakes (ARM) wrote:
> > 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! :)
>
> Fixing it up as I am applying :)

Cheers!

--
Cheers, Lorenzo