From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1IhL6s-000317-6t for qemu-devel@nongnu.org; Mon, 15 Oct 2007 04:15:34 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IhL6p-00030s-6y for qemu-devel@nongnu.org; Mon, 15 Oct 2007 04:15:33 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IhL6p-00030p-23 for qemu-devel@nongnu.org; Mon, 15 Oct 2007 04:15:31 -0400 Received: from ug-out-1314.google.com ([66.249.92.168]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1IhL6o-0007ox-IP for qemu-devel@nongnu.org; Mon, 15 Oct 2007 04:15:30 -0400 Received: by ug-out-1314.google.com with SMTP id m2so778637uge for ; Mon, 15 Oct 2007 01:15:29 -0700 (PDT) Message-ID: <4713219C.7070400@qumranet.com> Date: Mon, 15 Oct 2007 10:15:24 +0200 MIME-Version: 1.0 Subject: Re: [Qemu-devel] QEMU/MIPS & dyntick kernel References: <20071002200644.GA19140@hall.aurel32.net> <1191463182.31950.32.camel@rapid> <200710150223.50746.paul@codesourcery.com> In-Reply-To: <200710150223.50746.paul@codesourcery.com> Content-Type: multipart/alternative; boundary="------------080102010008000309090301" From: Dor Laor Reply-To: dor.laor@qumranet.com, 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" This is a multi-part message in MIME format. --------------080102010008000309090301 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Paul Brook wrote: >> 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. > > As of linux 2.6.24 there is dyn-tick kernel support for 64 bits. Expect for dyn-tick there is also the hpet option. > 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 > > > > --------------080102010008000309090301 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Paul Brook wrote: 
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.
As of linux 2.6.24 there is dyn-tick kernel support for 64 bits.
Expect for dyn-tick there is also the hpet option.
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

--------------080102010008000309090301--