Re: [PATCH v2] x86,mm: only trim the mm_cpumask once a second

From: Rik van Riel
Date: Tue Dec 03 2024 - 16:29:25 EST


On Tue, 2024-12-03 at 12:05 -0800, Dave Hansen wrote:
> On 12/3/24 11:48, Rik van Riel wrote:
> > Sending TLB flush IPIs to CPUs that are in the mm_cpumask, but no
> > longer running the program causes a regression in the will-it-scale
> > tlbflush2 test. This test is contrived, but a large regression here
> > might cause a small regression in some real world workload.
>
> The patch seems OK in theory, but this explanation doesn't sit right
> with me.
>
> Most of the will-it-scale tests including tlbflush2 have long-lived
> CPU-bound threads. They shouldn't schedule out much at all during the
> benchmark. I don't see how they could drive a significant increase in
> IPIs to cause a 10%+ regression.
>
> I'd much prefer that we understand the regression in detail before
> throwing more code at fixing it.
>
The tlb_flush2 threaded test does not only madvise in a
loop, but also mmap and munmap from inside every thread.

This should create massive contention on the mmap_lock,
resulting in threads going to sleep while waiting in
mmap and munmap.

https://github.com/antonblanchard/will-it-scale/blob/master/tests/tlb_flush2.c

--
All Rights Reversed.