From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=60523 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PsBnR-0008E0-AY for qemu-devel@nongnu.org; Wed, 23 Feb 2011 05:18:14 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PsBnP-0007FK-VH for qemu-devel@nongnu.org; Wed, 23 Feb 2011 05:18:13 -0500 Received: from mail-bw0-f46.google.com ([209.85.214.46]:49139) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PsBnP-0007Ew-Oi for qemu-devel@nongnu.org; Wed, 23 Feb 2011 05:18:11 -0500 Received: by bwz15 with SMTP id 15so3284347bwz.33 for ; Wed, 23 Feb 2011 02:18:10 -0800 (PST) Date: Wed, 23 Feb 2011 11:18:06 +0100 From: "Edgar E. Iglesias" Message-ID: <20110223101806.GA27880@edde.se.axis.com> References: <1298278286-9158-1-git-send-email-pbonzini@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1298278286-9158-1-git-send-email-pbonzini@redhat.com> 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: Paolo Bonzini Cc: qemu-devel@nongnu.org On Mon, Feb 21, 2011 at 09:51:22AM +0100, Paolo Bonzini wrote: > This series redoes the way time spent waiting for I/O is accounted to > the vm_clock. > > The current code is advancing qemu_icount before waiting for I/O. > Instead, after the patch qemu_icount is left aside (it is a pure > instruction counter) and qemu_icount_bias is changed according to > the actual amount of time spent in the wait. This is more > accurate, and actually works in the iothread case as well. > > (I started this as an experiment while trying to understand what was > going on. But it fixes the bug and does not break the no-iothread > case, so hey...). > > Patch 1 is a cleanup to Edgar's commit 225d02c (Avoid deadlock whith > iothread and icount, 2011-01-23). Thanks, this one was a good cleanup, I've applied it. > Patch 2 fixes another misunderstanding in the role of qemu_next_deadline. > > Patches 3 and 4 implement the actual new accounting algorithm. 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). > 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? 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? Cheers