Re: [RFC] mm: stress-ng --mremap triggers severe lruvec lock contention in populate/unmap paths

[Lorenzo Stoakes]

On Thu, Apr 09, 2026 at 11:12:39AM -0700, John Hubbard wrote:
>
> ...
> >>> +	 * Read VM_LOCKED before __get_user_pages(), which may drop
> >>> +	 * mmap_lock when FOLL_UNLOCKABLE is set, after which the vma
> >>> +	 * must not be accessed. The read is stable: mmap_lock is held
> >>> +	 * for read here, so mlock() (which needs the write lock)
> >>> +	 * cannot change VM_LOCKED concurrently.
> >>> +	 */
> >
> > BTW, not to nitpick (OK, maybe to nitpick :) this comments feels a bit
> > redundant. Maybe useful to note that the lock might be dropped (but you don't
> > indicate why it's OK to still assume state about the VMA), and it's a known
> > thing that you need a VMA write lock to alter flags, if we had to comment this
> > each time mm would be mostly comments :)
> >
> > So if you want a comment here I'd say something like 'the lock might be dropped
> > due to FOLL_UNLOCKABLE, but that's ok, we would simply end up doing a redundant
> > drain in this case'.
> >
> > But I'm not sure it's needed?
>
> I'm OK with just dropping the whole comment. I've lost my way lately with
> comment density. :)

Thanks, yeah I get this wrong myself often - I think tending towards more
comments is the better default :)

>
> >
> >>> +	need_drain = vma->vm_flags & VM_LOCKED;
> >
> > Please use the new VMA flag interface :)
>
> Oops, yes.

It's entirely forgiveable because this is massively new and pretty much nobody
but me and people who've bumped into it on review are all that aware :P

I mean I'll end up converting it all later anyway.

>
> I'm on the fence about whether to post an updated version of this.
> Maybe wait until someone pops up with a real need for it?
>
> Thoughts?

Yeah, let's wait for a real world case, otherwise we'll never be sure that we're
not solving the wrong problem I think.

>
> thanks,
> --
> John Hubbard
>

Cheers, Lorenzo