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

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

On Fri, Nov 06, 2026 at 03:24:20PM +0000, Lorenzo Stoakes (ARM) wrote:
> On Fri, Nov 06, 2026 at 09:26:01PM +0800, Vernon Yang wrote:
> > On Fri, Nov 06, 2026 at 12:07:53PM +0000, Lorenzo Stoakes (ARM) wrote:
> > > On reflection, I think this would be better implemented as something like:
> > >
> > > static void collapse_scan_mm_slot(unsigned int progress_max, ...)
> > > {
> > > 	unsigned int long lock_start = jiffies;
> > > 	...
> > >   	for_each_vma(vmi, vma) {
> > > 		...
> > >                 if (time_after(jiffies, lock_start) && mmap_lock_is_contended(mm)) {
> > >                         mmap_read_unlock(mm);
> > >                         cond_resched();
> > >                         mmap_read_lock(mm);
> > >                         lock_start = jiffies;
> > >                         vma_iter_set(&vmi, mm_slot->address);
> > >                         continue;
> > >                 }
> > > 	}
> > > }
> > >
> > > Which avoids magic numbers, and means if we hold the lock for 1-10ms (depending
> > > on HZ), which is a long time in the kernel to hold a lock, AND the lock is
> > > contended, we drop/reacquire.
> >
> > Looks good to me. Is the test result of this solution the same as the
> > current one?
>
> Thanks! I will update the commit to reflect the changes.

Hmm, actually the poor granularity of jiffies makes things measurably worse.

I think I have to just use a fixed constant still, and explain how it was
derived.

--
Cheers, Lorenzo