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

John Hubbard
2026-04-09T18:12:49Z

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