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
