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

["David Hildenbrand (Arm)" <david@kernel.org>]

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,

David