On 2 September 2015 at 06:51, Richard Henderson <r...@twiddle.net> wrote: > I've been looking at this problem off and on for the last week or so, > prompted by the sparc performance work. Although I havn't been able > to get a proper sparc64 guest install working, I see the exact same > problem with a mips guest. > > On alpha or x86, which seem to perform well, perf numbers for the > executable have about 30% of the execution time spent in cpu_exec. > For mips, on the other hand, we spend about 30% of the time in > routines related to tcg (re-)translation. > > Aurelien has a patch in his own branches that attempts to mitigate this > on mips by shadow caching more tlb entries. While this does improve > performace a bit, it employs a linear search through a large buffer, > with the effect of 30-ish % perf numbers for r4k_map_address. > > (One could probably improve things by hashing the data in that array, > rather than a linear search, but...) > > In the past we've talked about getting rid of retranslation entirely. > It's clever, but it certainly has its share of problems. I gave it > a go this weekend. > > The following isn't quite right. It fails to boot on sparc even with > our tiny test kernel. It also triggers an abort on mips, eventually. > But it's able to get all the way through to a prompt, and in the > process I can see that perf results are quite different -- much more > like results I see for alpha. > > Thoughts on the approach?
Looks sensible to me. For patches 1 2 4..16 20 Reviewed-by: Peter Maydell <peter.mayd...@linaro.org> Patches 3, 17, 19 I've sent "minor nit, otherwise r-by" followups to. Patch 18 is of course the meat of this series. It doesn't look obviously wrong but I want to put some more time into reviewing it tomorrow. My sparc test image (which is just the 32-bit debian from Aurelien's website) boots fine even with this patchset, though I didn't try stressing it at all. thanks -- PMM
