Re: [PATCH 7.2 v10 1/2] mm/mmu_gather: prepare to skip redundant sync IPIs

[Andrew Morton <akpm@linux-foundation.org>]

On Fri, 24 Apr 2026 08:52:16 -0700 Dave Hansen <dave.hansen@intel.com> wrote:

> On 4/24/26 08:04, Peter Zijlstra wrote:
> > So I don't like this at all.... The comment says there is a preceding
> > TLB flush, but there is nothing that guarantees there is. One would have
> > to go audit all users and ensure this is always true.
> > 
> > This thing is incredibly fragile.
> 
> Yeah, this seems like an attempt to apply a code solution to a data
> structure problem.
> 
> I think I talked about this in earlier iterations. But, ideally, what
> happens here is that the things doing the table freeing or collapsing or
> whatever would note in a data structure what they did.
> 
> Then the actual flushing code can look at the data structure and figure
> out what kind of flush it needs. Things like "do I need to flush on lazy
> CPUs?" Or, "have I done an IPI since the last page table free?"
> 
> But, if I remember from earlier in this thread, some of the callers of
> this stuff didn't have a nice data structure (like an mmu_gather) passed
> in to the places where it would be needed to exfiltrate the information.
> 
> I think Lance gave up on that because it looked too invasive to him.
> 
> But, I think this boils down to the code being too fragile as-is to
> support what Lance is trying to do. It actually needs some refactoring
> love before it can support the desired optimization. I'm not sure
> there's an easy way out here.

Well this is a bummer.  Looky:

> On a 64-core Intel x86 server, the CAL interrupt count in
> /proc/interrupts dropped from 646,316 to 785 when collapsing a 20 GiB
> range with this series applied.

It would have been nice.

Oh well, it's been a month with no progress so this patchset appears to
be before its time.  Thanks all, I'll drop this from the 7.1 queue.

(otoh, "a month with no progress" == "decently tested")!