On Fri, 24 Apr 2026 08:52:16 -0700 Dave Hansen <[email protected]> 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")!
