From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=41542 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PsBv0-0003rX-9p for qemu-devel@nongnu.org; Wed, 23 Feb 2011 05:26:03 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PsBuz-0008Ae-1l for qemu-devel@nongnu.org; Wed, 23 Feb 2011 05:26:02 -0500 Received: from mx1.redhat.com ([209.132.183.28]:21223) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PsBuy-0008AS-P6 for qemu-devel@nongnu.org; Wed, 23 Feb 2011 05:26:01 -0500 Message-ID: <4D64E0B2.3050900@redhat.com> Date: Wed, 23 Feb 2011 11:25:54 +0100 From: Paolo Bonzini MIME-Version: 1.0 References: <1298278286-9158-1-git-send-email-pbonzini@redhat.com> <20110223101806.GA27880@edde.se.axis.com> In-Reply-To: <20110223101806.GA27880@edde.se.axis.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: [PATCH 0/4] Improve -icount, fix it with iothread List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Edgar E. Iglesias" Cc: qemu-devel@nongnu.org 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