qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: FreeBSD timing issues and qemu (was: Re: [Qemu-devel] Re: Breakage w


From: Luigi Rizzo
Subject: Re: FreeBSD timing issues and qemu (was: Re: [Qemu-devel] Re: Breakage with local APIC routing)
Date: Wed, 9 Sep 2009 22:46:16 +0200
User-agent: Mutt/1.4.2.3i

On Mon, Sep 07, 2009 at 10:59:55PM +0200, Juergen Lock wrote:
> [I'm copying address@hidden because ppl there might know
> more about this...]
> 
>  qemu on FreeBSD hosts used to be able to run a (FreeBSD at least) guest
> with the same HZ as the host (like, 1000) with (mostly) proper timing
> once, but no longer. :(  It seems there are two problems involved:
> 
>  a) use of apic seems to cause the clock irq rate to be doubled to 2 * HZ
> (can anyone explain why?), i.e. a FreeBSD 7 guest on a FreeBSD 7 host
> only gets proper timing after setting hint.apic.0.disabled=1 via the
> loader.  (as can be verified by `vmstat -i' and `time sleep 2' in an
> installed guest or via the fixit->cdrom/dvd shell on a FreeBSD livefs
> or dvd1 iso.)
> 
>  b) qemu running on FreeBSD 8 hosts (and most likely head) has the
> additional problem of running its timers only at HZ/2 when using
> setitimer(2) (called `-clock unix' in qemu), as seen below.  (as also

this problem in 8.x is caused by the bug i described here yesterday:

http://lists.freebsd.org/pipermail/freebsd-current/2009-September/011393.html

In qeumu, the setitimer call (in file vl.c) has a timeout of 1 tick
which maps to callout_reset(..., 1, ...) and because (due to the bug)
8.x processes callouts 1 tick late, this effectively halves the clock rate.

> seen below, timer_settime(2) aka `-clock dynticks' in qemu behaves
> even worse, but that is similarly true on FreeBSD 7 which is why
> I removed the patch that enabled that from our qemu port(s) a few
> days ago.)  And the only reason FreeBSD 8 guests are usually less
> affected by these problems is they now reduce their HZ to 100 when
> they detect being run in a VM.  (which makes sense for other reasons
> as well, don't get me wrong...  but of course doesn't help when the
> host is running with HZ=100 too.)

cheers
luigi




reply via email to

[Prev in Thread] Current Thread [Next in Thread]