[Qemu-devel] Re: [PATCH 0/4] Improve -icount, fix it with iothread

[Edgar E. Iglesias]

On Wed, Feb 23, 2011 at 11:25:54AM +0100, Paolo Bonzini wrote:
> On 02/23/2011 11:18 AM, Edgar E. Iglesias wrote:
> > Sorry, I don't know the code well enough to give any sensible feedback
> > on patch 2 - 4. I did test them with some of my guests and things seem
> > to be OK with them but quite a bit slower.
> > I saw around 10 - 20% slowdown with a cris guest and -icount 10.
> >
> > The slow down might be related to the issue with super slow icount together
> > with iothread (adressed by Marcelos iothread timeout patch).
> 
> 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.

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.

Don't know if that info helps...


> Have you tested without iothread too, both to check the speed and to 
> ensure this introduces no regressions?

I tried now, I see no regression without iothread.

> > >  With these patches, iothread "-icount N" doesn't work when the actual
> > >  execution speed cannot keep up with the requested speed; the execution
> > >  in that case is not deterministic.  It works when the requested speed
> > >  is slow enough.
> >
> > Sorry, would you mind explaning this a bit?
> 
> -icount 0 doesn't give 1000 BogoMIPS unless the machine is fast enough 
> to sustain it.  But that's a bug.  These patches are meant to be a start.
> 
> > For example, if I have a machine and guest sw that does no IO. It runs
> > the CPU and only uses devices that use the virtual time (e.g timers
> > and peripherals that compute stuff). Can I expect the guest (with
> > fixed icount speed "-icount N") to run deterministically regardless of
> > host speed?
> 
> Right now, only if the N is large enough for the host machine to sustain 
> that speed.

OK thanks.

Cheers