[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH 2/2] [RFC] time: refactor QEMU timer to use GHRT
From: |
Jan Kiszka |
Subject: |
Re: [Qemu-devel] [PATCH 2/2] [RFC] time: refactor QEMU timer to use GHRTimer |
Date: |
Mon, 22 Aug 2011 22:49:37 +0200 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666 |
On 2011-08-22 22:36, Anthony Liguori wrote:
> On 08/22/2011 03:28 PM, Jan Kiszka wrote:
>> On 2011-08-22 21:21, Anthony Liguori wrote:
>>> This replaces all of the QEMU timer code with GHRTimer, dramatically
>>> simplifying
>>> time keeping in QEMU while making it possible to use QEMUTimer code
>>> outside of
>>> the main loop. The later is critical to building unit tests.
>>>
>>> This is an RFC because I'm sure this breaks things as it changes
>>> things. QEMU
>>> time keeping is quite a mess today. Here's what we do today:
>>>
>>> 1) We have three clocks:
>>> a) the real time clock, based on system time, not monotonic
>>> b) the host clock, based on the real time clock, monotonic by
>>> detecting
>>> movements backward in time
>>> c) the vm clock, based on real time clock but may start/stop with
>>> the guest
>>
>> Not quite correct. We have:
>>
>> - QEMU_CLOCK_REALTIME: Based on monotonic source *if* the host
>> supports it (there were probably once some stone-old Linuxes or
>> BSDs), otherwise based on gettimeofday, i.e. non-monotonic. Always
>> monotonic on Windows.
>
> The only clock on Linux that is truly monotonic is CLOCK_MONOTONIC_RAW
> which is very new (2.6.28+). CLOCK_MONOTONIC is not actually monotonic
> as it's subject to adjustments.
CLOCK_MONOTONIC may be subject to frequency tuning while
CLOCK_MONOTONIC_RAW is not. That does not and must not (for POSIX
compliance) make the former non-monotonic.
>
>> - QEMU_CLOCK_VIRTUAL: Without -icount, same as above, but stops when
>> the guest is stopped. The offset to compensate for stopped
>> times is based on TSC, not sure why. With -icount, things get more
>> complicated, Paolo had some nice explanations for the details.
>>
>> - QEMU_CLOCK_HOST: That's the one always based on the host's system
>> time (CLOCK_REALTIME)
>> + it takes potentially configured offsets into acount
>> + users of that clock can register callbacks on time warps into the
>> past (to adjust pending timers)
>
> Right, my assertion is that time warps are a bug as far as QEMU is
> concerned. Is there any reason why the guest should care at all about
> time warping in the host?
Yes, to synchronize on an accurate host clock source without the need to
add NTP-like services (or kvmclock) to the guest. So the warps are
conceptionally valid, though still not very welcome.
>
>>> 2) A "cpu ticks" clock that uses platform specific mechanisms (inline
>>> asm)
>>>
>>> 3) Various clock source implementations that may use a periodic timer
>>> or a
>>> a dynamic time source. We have different implementations for
>>> different
>>> platforms
>>>
>>> 4) Time events are delivered via SIGALRM which means we end up
>>> getting EINTRs
>>> very often in QEMU. This is fairly annoying. Signals also race
>>> against
>>> select leading to a very ugly set of work arounds involving
>>> writing data to
>>> pipes. This is the sort of stuff in Unix programming that I wish
>>> I never had
>>> to learn about and am very eager to eliminate in QEMU :-)
>>>
>>> (2) is just plain broken. In modern operating systems,
>>> gettimeofday() is
>>> optimized CPU instructions when they can be used safely. Often they
>>> can't be
>>> used safely and we ignore that in QEMU. For instance, on x86, RDTSC
>>> races with
>>> the scheduler (not to mention that the TSC is infamously unstable
>>> across cores).
>>> The kernel does the right thing here and provides the fastest method
>>> that's
>>> correct.
>>
>> I basically agree. Likely, these optimizations date back to the days
>> Linux had no fast gettimeofday syscalls. Not sure what the state on
>> other UNIXes is, but it's likely not worth keeping these optimizations.
>> Let's drop that one first and separately.
>>
>>>
>>> (1.a) seems like a bug more than a feature. I don't see a lot of
>>> disadvantages
>>> to using a monotonic time source.
>>>
>>> (1.b) is a bit naive in its current form. Modern kernels export a truly
>>> monotonic time source which has a reliable frequency. Even though
>>> (1.b) detects
>>> backwards jumps, it doesn't do anything about large forward jumps
>>> which can also
>>> be problematic.
>>
>> These two assessments are partly just wrong, partly fail to see the real
>> use case. QEMU_CLOCK_HOST serves the very valid scenarios where a guest
>> clock shall be kept synchronized on the host time, also following its
>> jumps accordingly without stalling timers.
>
> The only reason we see jumps at all is because we're using
> CLOCK_MONOTONIC or CLOCK_REALTIME. If we used CLOCK_MONOTONIC_RAW, we
> don't see any jumps at all.
CLOCK_MONOTONIC will not jump backward as well, so is perfectly fine and
better portable. Backward jumps cannot be avoided when using a host
system clock that is subject to follow a more accurate external source.
But having such source for RTC emulation e.g. is a useful feature.
Jan
signature.asc
Description: OpenPGP digital signature
Re: [Qemu-devel] [PATCH 2/2] [RFC] time: refactor QEMU timer to use GHRTimer, Paolo Bonzini, 2011/08/23
Re: [Qemu-devel] [PATCH 1/2] main: add high resolution GSource based timer, Anthony Liguori, 2011/08/22