From: James Clarke <jrtc27@xxxxxxxxxx>
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.
?τθΊ{.nΗ+?·????+%?Λ?±ιέΆ??w?Ί{.nΗ+?·¬??ά?)ξΗψ§Ά?ʽά¨}©?²Ζ zΪ&j:+v?¨ώψ ―ω ?w?ώ?ΰ2?ή?¨θΪ&ʼ)ίʽ«aΆΪ??ϋΰzΏδzΉή?ϊ+?ω???έʼj??wθώf
