On 02/23/2011 12:08 PM, Edgar E. Iglesias wrote:
> No, this supersedes Marcelo's patch. 10-20% doesn't seem comparable to
> "looks like it deadlocked" anyway. Also, Jan has ideas on how to remove
> the synchronization overhead in the main loop for TCG+iothread.
I see. I tried booting two of my MIPS and CRIS linux guests with iothread
and -icount 4. Without your patch, the boot crawls super slow. Your patch
gives a huge improvement. This was the "deadlock" scenario which I
mentioned in previous emails.
Just to clarify the previous test where I saw slowdown with your patch:
A CRIS setup that has a CRIS and basically only two peripherals,
a timer block and a device (X) that computes stuff but delays the results
with a virtual timer. The guest CPU is 99% of the time just
busy-waiting for device X to get ready.
This latter test runs in 3.7s with icount 4 and without iothread,
with or without your patch.
Thanks for testing this.
With icount 4 and iothread it runs in ~1m5s without your patch and
~1m20s with your patch. That was the 20% slowdown I mentioned earlier.
Ok, so it is in both cases with iothread. We go from 16x slowdown to
19x on one testcase :) and "huge improvement" on another. (Also, the
CRIS images on qemu.org simply hang for me without my patch and numeric
icount---and the watchdog triggers---so that's another factor in favor
of the patches). I guess we can live with the slowdown for now, if
somebody else finds the patch okay.
Do you have images for the slow test?
Paolo
