Re: [PATCH v2] mm/vma: avoid spurious write locks when mm->mm_lock_seq overflows

[Pedro Falcato]

On Wed, Oct 28, 2026 at 03:04:07PM +0000, Lorenzo Stoakes (ARM) wrote:
> On Mon, Oct 19, 2026 at 01:19:45PM +0100, Lorenzo Stoakes (ARM) wrote:
> > On Mon, Oct 19, 2026 at 10:53:27AM +0100, Pedro Falcato wrote:
> > > On Fri, Oct 16, 2026 at 12:34:33PM +0100, Lorenzo Stoakes (ARM) wrote:
> > > I'm concerned by the possible latency when doing this to many VMAs. Do you
> > > have any numbers?
> >
> > No, somebody schloppened a patch for a real issue and I haven't the time to do
> > even the things I need to do let alone 'here's a new task' stuff :)
> >
> > However, this is a simple write to every VMA, done at the point the mmap write
> > lock is held with all VMA write locks dropped.
> >
> > It was implemented such that:
> >
> > * No VMA write lock is taken on the VMAs.
> > * VMA read locks can proceed.
> >
> > I.e. it amounts to a loop over VMAs and a write to a field.
> >
> > I don't think you could possibly do more to reduce latency here, and you
> > absolutely have to update this field across the board.
> >
> > Under any realistic workloads this will occur at worst ~days intervals, often
> > far longer, and likely you will see quite some gaps between separate processes
> > experiencing it.
> >
> > There's also an upper bound of vm.max_map_count per-process, so it can't explode
> > into something truly insane.
> >
> > Most processes don't have that many VMAs, other than certain steam games :) so
> > it's hard to imagine there really would be that much latency here.
> >
> > And the latency is occurring on one thread, which is performing an mmap unlock,
> > so nobody sane will put that on a hot path.
> 
> Sorry, I forgot about this and didn't get numbers to back this.
> 
> I had an LLM go get numbers on this, all in ms on my threadripper (but numbers
> should scale similarly) with fork() + munmap() all VMAs for comparison:
> 
> (all ms)
> 
>       VMAs      reset    reset     fork()     munmap()
>                 (warm)   (cold)    (cold)     all VMAs
>   --------    -------  -------    -------    ---------
>      1,000      0.006    0.041       0.33         0.43
>     10,000      0.072    0.36        2.1          4.2
>     65,500      0.61     2.4        14.1         33.5	(default)
>    262,144      5.3      9.6        60          168
>  1,048,000     34.7     39.2       237          691
>  4,194,304    162      163         954         2810
> 
> It happens on a random VMA write lock release, so there could be tail
> latency, but it'd be tail latency on the scale of ~weeks for normal
> workloads, and (assuming max map count reached at default limit) a ~2ms
> latency for an operation such as mprotect(), madvise(), mmap() or munmap()
> which shouldn't be placed in any situation where the latency of that call
> matters.
> 
> One call in 2^31 is the
> 99.99999995th percentile, far beyond any latency target anyone measures.
> 
> The amortised time per write-lock cycle is ~18 picoseconds (0.018 ns).

Thanks, this addresses my concerns :)

> 
> Interestingly, the runner observed khugepaged-induced mmap lock stalls of
> ~100ms, far far more regularly, which seriously exceeds any of these
> numbers, about which I assume we haven't had too much complaint.

Wow, that's horrible.

-- 
Pedro