All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dor Laor <dor.laor@gmail.com>
To: qemu-devel@nongnu.org
Cc: "J. Mayer" <l_indien@magic.fr>
Subject: Re: [Qemu-devel] QEMU/MIPS & dyntick kernel
Date: Mon, 15 Oct 2007 10:15:24 +0200	[thread overview]
Message-ID: <4713219C.7070400@qumranet.com> (raw)
In-Reply-To: <200710150223.50746.paul@codesourcery.com>

[-- Attachment #1: Type: text/plain, Size: 1312 bytes --]

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
>
>
>
>   


[-- Attachment #2: Type: text/html, Size: 1784 bytes --]

  reply	other threads:[~2007-10-15  8:15 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-10-02 20:06 QEMU/MIPS & dyntick kernel Aurelien Jarno
2007-10-02 20:06 ` [Qemu-devel] " Aurelien Jarno
2007-10-02 20:27 ` Avi Kivity
2007-10-02 20:37   ` Aurelien Jarno
2007-10-02 20:48     ` Alan Cox
2007-10-02 20:48       ` Alan Cox
2007-10-02 20:57       ` Aurelien Jarno
2007-10-02 20:57         ` Aurelien Jarno
2007-10-02 22:35         ` Ralf Baechle
2007-10-02 22:35           ` Ralf Baechle
2007-10-04  1:59 ` J. Mayer
2007-10-04 16:19   ` Daniel Jacobowitz
2007-10-15  1:23   ` Paul Brook
2007-10-15  8:15     ` Dor Laor [this message]
2007-10-15 15:05 ` Thiemo Seufer
2007-10-15 15:58   ` Ralf Baechle
2007-10-15 15:58     ` Ralf Baechle
2007-10-15 16:20     ` Thiemo Seufer
2007-10-15 16:20       ` Thiemo Seufer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4713219C.7070400@qumranet.com \
    --to=dor.laor@gmail.com \
    --cc=dor.laor@qumranet.com \
    --cc=l_indien@magic.fr \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.