From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=55761 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PmQve-0005G4-Al for qemu-devel@nongnu.org; Mon, 07 Feb 2011 08:14:59 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PmQvF-0002zx-Qd for qemu-devel@nongnu.org; Mon, 07 Feb 2011 08:14:30 -0500 Received: from mx1.redhat.com ([209.132.183.28]:22484) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PmQvF-0002zt-FW for qemu-devel@nongnu.org; Mon, 07 Feb 2011 08:14:29 -0500 Message-ID: <4D4FF02F.2030309@redhat.com> Date: Mon, 07 Feb 2011 15:14:23 +0200 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [RFC: 0/2] patch for QEMU HPET periodic timer emulation to alleviate time drift References: <480481933.225059.1296734409954.JavaMail.root@zmail07.collab.prod.int.phx2.redhat.com> <1375835067.226263.1296740625327.JavaMail.root@zmail07.collab.prod.int.phx2.redhat.com> <4D4AC99A.2070803@siemens.com> <4D4B0B07.2040904@codemonkey.ws> <4D4B1CF8.8040800@web.de> <4D4B5F23.7040801@codemonkey.ws> <4D4BBF55.9060000@web.de> <4D4FE6BF.5080502@redhat.com> <4D4FEF81.1040603@codemonkey.ws> In-Reply-To: <4D4FEF81.1040603@codemonkey.ws> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Glauber Costa , Jan Kiszka , qemu-devel , kvm , Ulrich Obergfell On 02/07/2011 03:11 PM, Anthony Liguori wrote: > On 02/07/2011 06:34 AM, Avi Kivity wrote: >> On 02/04/2011 10:56 AM, Jan Kiszka wrote: >>> > >>> > This should be a rare event. If you are missing 50% of your >>> > notifications, not amount of gradual catchup is going to help you >>> out. >>> >>> But that's the only thing this patch is after: lost ticks at QEMU >>> level. >> >> Most lost ticks will happen at the vcpu level. The iothread has low >> utilization and will therefore be scheduled promptly, whereas the >> vcpu thread may have high utilization and will thus be preempted. >> When it is preempted for longer than the timer tick, we will see >> vcpu-level coalescing. All it takes is 2:1 overcommit to see time go >> half as fast; I don't think you'll ever see that on bare metal. > > But that's not to say that doing something about lost ticks in QEMU > isn't still useful. > If it doesn't solve the majority of the problems it isn't very useful IMO. It's a good first step, but not sufficient for real world use with overcommit. -- error compiling committee.c: too many arguments to function