On Sat, Jan 8, 2022 at 2:04 PM Andy Lutomirski <luto@xxxxxxxxxx> wrote:
>
> So this requires that all architectures actually walk all relevant
> CPUs to see if an IPI is needed and send that IPI. On architectures
> that actually need an IPI anyway (x86 bare metal, powerpc (I think)
> and others, fine. But on architectures with a broadcast-to-all-CPUs
> flush (ARM64 IIUC), then the extra IPI will be much much slower than a
> simple load-acquire in a loop.
... hmm. How about a hybrid scheme?
(a) architectures that already require that IPI anyway for TLB invalidation (ie x86, but others too), just make the rule be that the TLB flush by exit_mmap() get rid of any lazy TLB mm references. Which they already do.
(b) architectures like arm64 that do hw-assisted TLB shootdown will have an ASID allocator model, and what you do is to use that to either
(b') increment/decrement the mm_count at mm ASID allocation/freeing time
(b'') use the existing ASID tracking data to find the CPU's that have that ASID
(c) can you really imagine hardware TLB shootdown without ASID allocation? That doesn't seem to make sense. But if it exists, maybe that kind of crazy case would do the percpu array walking.
(Honesty in advertising: I don't know the arm64 ASID code - I used to know the old alpha version I wrote in a previous lifetime - but afaik any ASID allocator has to be able to track CPU's that have a particular ASID in use and be able to invalidate it).
Hmm. The x86 maintainers are on this thread, but they aren't even the problem. Adding Catalin and Will to this, I think they should know if/how this would fit with the arm64 ASID allocator.
Will/Catalin, background here:
for my objection to that special "keep non-refcounted magic per-cpu pointer to lazy tlb mm".
Linus
