On 5/10/10, Mark Cave-Ayland <mark.cave-ayl...@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.
