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

[Paolo Bonzini <pbonzini@redhat.com>]

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.

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

> >  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.

Paolo