Re: [Qemu-devel] [RFC 00/20] Do away with TB retranslation

[Peter Maydell]

On 2 September 2015 at 06:51, Richard Henderson <address@hidden> 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 <address@hidden>

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