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

[John Hubbard <jhubbard@nvidia.com>]

On 4/9/26 11:03 AM, Lorenzo Stoakes wrote:
> On Tue, Apr 07, 2026 at 05:35:18PM -0700, Hugh Dickins wrote:
>> On Tue, 7 Apr 2026, John Hubbard wrote:
>>> On 4/7/26 1:09 PM, Joseph Salisbury wrote:
...
>> Thanks for the Cc.  I'm not convinced that we should be making such a
>> change, just to avoid the stress that an avowed stresstest is showing;
>> but can let others debate that - and, need it be said, I have no
>> problem with Joseph trying your patch.
> 
> Yeah, the test case (as said by others also) is rather synthetic, and it's a
> test designed to saturate, if not I/O throttled by swap then we hammer the
> populate path. It feels like a micro-optimisation for something that is not (at
> least not yet demonstrated to be) an actual problem.
> 
> stress-ng is not a benchmarking tool per se, it's designed to eek out bugs.
> 
> So really we need to see a real-world case I think.

Absolutely. And to be honest, I saw "Oracle" and recalled that they are
always doing things will zillions of threads, so I assumed that a real
world case was waiting right behind this. But maybe not, after all?

...
>>> +	 * 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. :)

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

Oops, yes.

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?

thanks,
-- 
John Hubbard