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

[Suren Baghdasaryan]

On Wed, Oct 28, 2026 at 8:06 AM Pedro Falcato <pfalcato@xxxxxxx> wrote:
>
> 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 :)

Sorry for missing this fix before (due to my vacation) and only now
finding it. From a quick look it seems correct but I'll spend some
more time reviewing and testing it.
Thanks Lorenzo for the fix! I completely overlooked this overflow
side-effect. And thanks to Liam for flagging it!

>
> >
> > 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