On Sun, Jan 9, 2022, at 1:51 PM, Linus Torvalds wrote: > [ Ugh, I actually went back and looked at Nick's patches again, to > just verify my memory, and they weren't as pretty as I thought they > were ] > > On Sun, Jan 9, 2022 at 12:48 PM Linus Torvalds > <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: >> >> I'd much rather have a *much* smaller patch that says "on x86 and >> powerpc, we don't need this overhead at all". I can whip this up. It won’t be much smaller — we still need the entire remainder of the series as prep, and we’ll end up with an if (arch needs mmcount) somewhere, but it’s straightforward. But I reserve the right to spam you with an even bigger patch, because mm_cpumask also pingpongs, and I have some ideas for helping that out too. Also: >> exit_mmap(); >> for each cpu still in mm_cpumask: >> smp_load_acquire >> >> That's it, unless the mm is actually in use > > Ok, now do this for a machine with 1024 CPU's. > > And tell me it is "scalable". > Do you mean a machine with 1024 CPUs and 2 bits set in mm_cpumask or 1024 CPU with 800 bits set in mm_cpumask? In the former case, this is fine. In the latter case, *on x86*, sure it does 800 loads, but we're about to do 800 CR3 writes to tear the whole mess down, so the 800 loads should be in the noise. (And this series won't actually do this anyway on bare metal, since exit_mmap does the shootdown.)
