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
