From: James Clarke <jrt...@jrtc27.com> Date: Thu, 27 Oct 2016 17:02:32 +0100
> I was just testing it on the IIIi when I got this. Anyway, it seems to work > fine. > It hasn’t (yet) had one of the stupidly high allocations, but it did flush a > block > of 3658 pages just fine (assuming the flush actually worked). Similarly for > the T1. Thanks for testing. I'll post the final patch I committed. > The cut-off seems pretty arbitrary, and the only way to determine it properly > would > be benchmarking (or finding out what the relevant delays are). Given x86 uses > 33, > 32 or 64 seem perfectly fine, but going into the hundreds doesn’t sound stupid > either... For such small numbers it’s probably hardly going to matter. It's not too hard to write a kernel module which just does dummy TLB flushes in the loop and count the cycles using the %tick register. And I plan to hack on something like that soon'ish. Another part of the equation is that it blows away, at a minimum, all kernel TLB entries. And that has a certain cost too.
