From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [Qemu-devel] Re: [RFC: 0/2] patch for QEMU HPET periodic timer emulation to alleviate time drift Date: Mon, 07 Feb 2011 15:46:54 +0200 Message-ID: <4D4FF7CE.6020005@redhat.com> References: <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> <4D4FF02F.2030309@redhat.com> <4D4FF24A.7000004@codemonkey.ws> <20110207134104.GE14984@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Anthony Liguori , Jan Kiszka , qemu-devel , Glauber Costa , Ulrich Obergfell , kvm To: Gleb Natapov Return-path: Received: from mx1.redhat.com ([209.132.183.28]:51169 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752563Ab1BGNrB (ORCPT ); Mon, 7 Feb 2011 08:47:01 -0500 In-Reply-To: <20110207134104.GE14984@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On 02/07/2011 03:41 PM, Gleb Natapov wrote: > On Mon, Feb 07, 2011 at 07:23:22AM -0600, Anthony Liguori wrote: > > On 02/07/2011 07:14 AM, Avi Kivity wrote: > > >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. > > > > Even if we have a way to detect coalescing, we still need to make > > sure we don't lose ticks in QEMU. So regardless of whether it > > solves the majority of problems, we need this anyway. > > > Actually it is very strange we lose them. Last time I checked vm_clock > worked in such a way that if ticks were lost due to qemu not been scheduled > for a long time timer callback was repeatedly fired to compensate for > missed wakeups. > That's quite pointless, since those interrupts will be coalesced by the guest. -- error compiling committee.c: too many arguments to function