From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:59743) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qvb76-0008Rp-7L for qemu-devel@nongnu.org; Mon, 22 Aug 2011 16:28:53 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Qvb73-0003Nd-AC for qemu-devel@nongnu.org; Mon, 22 Aug 2011 16:28:52 -0400 Received: from fmmailgate01.web.de ([217.72.192.221]:40420) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qvb72-0003NT-MW for qemu-devel@nongnu.org; Mon, 22 Aug 2011 16:28:49 -0400 Message-ID: <4E52BBF2.3040102@web.de> Date: Mon, 22 Aug 2011 22:28:34 +0200 From: Jan Kiszka 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> In-Reply-To: <1314040874-9259-2-git-send-email-aliguori@us.ibm.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig964743C3FBBE2CA4D0390678" Sender: jan.kiszka@web.de 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: Anthony Liguori Cc: Paolo Bonzini , qemu-devel@nongnu.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig964743C3FBBE2CA4D0390678 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable On 2011-08-22 21:21, Anthony Liguori wrote: > This replaces all of the QEMU timer code with GHRTimer, dramatically si= mplifying > time keeping in QEMU while making it possible to use QEMUTimer code out= side of > the main loop. The later is critical to building unit tests. >=20 > This is an RFC because I'm sure this breaks things as it changes things= =2E QEMU > time keeping is quite a mess today. Here's what we do today: >=20 > 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 detecti= ng > 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. - 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) >=20 > 2) A "cpu ticks" clock that uses platform specific mechanisms (inline a= sm) >=20 > 3) Various clock source implementations that may use a periodic timer o= r a > a dynamic time source. We have different implementations for differ= ent > platforms >=20 > 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 aga= inst > 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 :-) >=20 > (2) is just plain broken. In modern operating systems, gettimeofday() = is > optimized CPU instructions when they can be used safely. Often they ca= n't be > used safely and we ignore that in QEMU. For instance, on x86, RDTSC ra= ces with > the scheduler (not to mention that the TSC is infamously unstable acros= s cores). > The kernel does the right thing here and provides the fastest method th= at'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. >=20 > (1.a) seems like a bug more than a feature. I don't see a lot of disad= vantages > to using a monotonic time source. >=20 > (1.b) is a bit naive in its current form. Modern kernels export a trul= y > 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. 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 --------------enig964743C3FBBE2CA4D0390678 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk5Su/oACgkQitSsb3rl5xQ2CgCgi2PUFDCKom8CusxxFWLgig1j AkkAnjC7L2bP+qaf6EtNIQK8DA9qzu1B =roqT -----END PGP SIGNATURE----- --------------enig964743C3FBBE2CA4D0390678--