From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1IhEgY-0000qJ-PV for qemu-devel@nongnu.org; Sun, 14 Oct 2007 21:23:58 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IhEgW-0000os-Df for qemu-devel@nongnu.org; Sun, 14 Oct 2007 21:23:57 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IhEgW-0000op-7F for qemu-devel@nongnu.org; Sun, 14 Oct 2007 21:23:56 -0400 Received: from mail.codesourcery.com ([65.74.133.4]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1IhEgV-0005Bj-Jb for qemu-devel@nongnu.org; Sun, 14 Oct 2007 21:23:55 -0400 From: Paul Brook Subject: Re: [Qemu-devel] QEMU/MIPS & dyntick kernel Date: Mon, 15 Oct 2007 02:23:50 +0100 References: <20071002200644.GA19140@hall.aurel32.net> <1191463182.31950.32.camel@rapid> In-Reply-To: <1191463182.31950.32.camel@rapid> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200710150223.50746.paul@codesourcery.com> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: "J. Mayer" > There seem to have specific problems when using dynticks in Qemu. What I > can see is that it makes the PowerPC emulation quite unusable, at least > on my PC, which is an amd64 (with a fix CPU frequency), no matter if I > run 32 or 64 bits mode. I'd expect to see the same problems running a non-dynticks qemu on a heavily loaded host, or a host that did not have /dev/rtc available. IIRC vanilla amd64-linux does not yet use the new kernel high resolution timer infrastructure, so posix timers (as used by dynticks) have a fairly high jitter+latency compared to /dev/rtc. The tradeoff is that on hosts that do implement high resolution timers (e.g. i386) you get lower overhead and/or more accurate emulation. I don't think there's any deterministic way of figuring out which is best. It may be feasible to switch mechanisms dynamically if it's obvious one is sucking, but I'm not sure how well that would work in practice. The only reliable solution is to isolate qemu from the host realtime characteristics, though that has its own set of issues. I hope to have this implemented fairly soon. Paul