|
From: | Paolo Bonzini |
Subject: | [Qemu-devel] Re: [PATCH 0/4] Improve -icount, fix it with iothread |
Date: | Wed, 23 Feb 2011 11:25:54 +0100 |
User-agent: | Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14 Lightning/1.0b3pre Mnenhy/0.8.3 Thunderbird/3.1.7 |
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
[Prev in Thread] | Current Thread | [Next in Thread] |