From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:52301) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QvbE9-0005ll-L4 for qemu-devel@nongnu.org; Mon, 22 Aug 2011 16:36:10 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QvbE8-0004ka-G2 for qemu-devel@nongnu.org; Mon, 22 Aug 2011 16:36:09 -0400 Received: from mail-gw0-f45.google.com ([74.125.83.45]:65288) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QvbE8-0004kW-66 for qemu-devel@nongnu.org; Mon, 22 Aug 2011 16:36:08 -0400 Received: by gwb19 with SMTP id 19so3895871gwb.4 for ; Mon, 22 Aug 2011 13:36:07 -0700 (PDT) Message-ID: <4E52BDB4.5060704@codemonkey.ws> Date: Mon, 22 Aug 2011 15:36:04 -0500 From: Anthony Liguori MIME-Version: 1.0 References: <1314040874-9259-1-git-send-email-aliguori@us.ibm.com> <1314040874-9259-2-git-send-email-aliguori@us.ibm.com> <4E52BBF2.3040102@web.de> In-Reply-To: <4E52BBF2.3040102@web.de> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 2/2] [RFC] time: refactor QEMU timer to use GHRTimer List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: Paolo Bonzini , Anthony Liguori , qemu-devel@nongnu.org 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. > - 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? >> 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. Regards, Anthony Liguori > I haven't looked at the timer parts yet, but the clock assessments > indicate that some more careful thoughts are required. Strong NACK for > breaking QEMU_CLOCK_HOST in any case. > > I do agree that there is likely room for cleanups, specifically when > demanding a sane POSIX/WIN32 host and/or reusing CLOCK_MONOTONIC > abstractions. > > Jan >