Re: [Qemu-devel] Re: sparc64 lazy conditional codes evaluation

[Blue Swirl <blauwirbel@gmail.com>]

On 5/10/10, Mark Cave-Ayland <mark.cave-ayland@siriusit.co.uk> wrote:
> Blue Swirl wrote:
>
>
> > Thanks a lot, with this patch my tests passed! I applied the combined
> patch.
> >
>
>  Yes, I definitely see an improvement with this patch - at least my Debian
> lenny SPARC boot cd doesn't randomly kernel panic any more. It looks as if
> it now just can't find /init which could just be due to an incorrect device
> mapping somewhere.
>
>
> > I also did a bit of refactoring to get the original Sparc64 issue fixed.
> >
>
>  However, one thing I did notice is that this does introduce a noticeable
> performance penalty. With OpenBIOS SVN head I see the following:
>
>  With commit 72139e83a98eba2bfed2dbc2db2818fb19e47ca0 (just
> before the changes):
>
>  [   59.225406] Failed to execute /init
>  [   59.304088] Kernel panic - not syncing: No init found.  Try passing
> init= option to kernel.
>  [   59.450313] Press Stop-A (L1-A) to return to the boot prom
>
>  With commit 5a834bb47c373e887de5210b7ceae96e1ef413f7 (just
> after the changes):
>
>  [   70.384466] Failed to execute /init
>  [   70.474804] Kernel panic - not syncing: No init found.  Try passing
> init= option to kernel.
>
>
>  So while it's technically correct, it seems to have added ~15% overhead to
> the emulation :(

Guest time can be unreliable, it could also indicate that Linux
executes a lot more timer interrupts. Could you retest and measure the
wall clock time?

I think the C flag change should only increase performance. The next
commit may have negative effects because more work is done every
interrupt, but it's also more correct now.