From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [Qemu-devel] [PATCH] [RFC] Fix time drift of rtc clock + general support Date: Mon, 24 Mar 2008 09:47:28 +0200 Message-ID: <47E75C90.1020706@qumranet.com> References: <1206282453.18800.31.camel@localhost.localdomain> <200803231619.32472.paul@codesourcery.com> <1206312059.30051.9.camel@localhost.localdomain> <200803232329.10474.paul@codesourcery.com> <47E7550D.3070706@qumranet.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: kvm-devel , qemu-devel@nongnu.org To: Paul Brook Return-path: In-Reply-To: <47E7550D.3070706@qumranet.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kvm-devel-bounces@lists.sourceforge.net Errors-To: kvm-devel-bounces@lists.sourceforge.net List-Id: kvm.vger.kernel.org Avi Kivity wrote: > Paul Brook wrote: >> >>>> a new timer will be fired to try inject it again soon (==0.1msec) >>>> >> >> If the guest is missing interrupts, the chances of a 0.1ms interval >> working are not great. Most likely It's either going trigger >> immediately, or be delayed significantly and you're going to end up >> even further behind. > > If 0.1 ms is within qemu's timeslice, then qemu should get the wakeup > on time (assuming a host with high resolution timers). > >> If triggering immediately is OK then why not do that all the time? >> > > Triggering immediately doesn't help, the guest likely has interrupts > blocked processing the same interrupt. > >> If triggering immediately is not acceptable then you're still going >> to loose interrupts. >> > > You're still accounting for them, so if the load decreases eventually > it's going to catch up. > > btw, the better solution here is to wait until the guest is ready for timer interrupt injection again, but that's not as easy as arming a timer. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Jdjf8-0004DC-SZ for qemu-devel@nongnu.org; Mon, 24 Mar 2008 06:12:18 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Jdjf5-0004C6-MX for qemu-devel@nongnu.org; Mon, 24 Mar 2008 06:12:18 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Jdjf5-0004C2-I9 for qemu-devel@nongnu.org; Mon, 24 Mar 2008 06:12:15 -0400 Received: from mx20.gnu.org ([199.232.41.8]) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Jdjf5-0005tw-7G for qemu-devel@nongnu.org; Mon, 24 Mar 2008 06:12:15 -0400 Received: from bzq-179-150-194.static.bezeqint.net ([212.179.150.194] helo=il.qumranet.com) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1JdhTW-0000Iw-PD for qemu-devel@nongnu.org; Mon, 24 Mar 2008 03:52:11 -0400 Message-ID: <47E75C90.1020706@qumranet.com> Date: Mon, 24 Mar 2008 09:47:28 +0200 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [kvm-devel] [Qemu-devel] [PATCH] [RFC] Fix time drift of rtc clock + general support References: <1206282453.18800.31.camel@localhost.localdomain> <200803231619.32472.paul@codesourcery.com> <1206312059.30051.9.camel@localhost.localdomain> <200803232329.10474.paul@codesourcery.com> <47E7550D.3070706@qumranet.com> In-Reply-To: <47E7550D.3070706@qumranet.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paul Brook Cc: kvm-devel , qemu-devel@nongnu.org Avi Kivity wrote: > Paul Brook wrote: >> >>>> a new timer will be fired to try inject it again soon (==0.1msec) >>>> >> >> If the guest is missing interrupts, the chances of a 0.1ms interval >> working are not great. Most likely It's either going trigger >> immediately, or be delayed significantly and you're going to end up >> even further behind. > > If 0.1 ms is within qemu's timeslice, then qemu should get the wakeup > on time (assuming a host with high resolution timers). > >> If triggering immediately is OK then why not do that all the time? >> > > Triggering immediately doesn't help, the guest likely has interrupts > blocked processing the same interrupt. > >> If triggering immediately is not acceptable then you're still going >> to loose interrupts. >> > > You're still accounting for them, so if the load decreases eventually > it's going to catch up. > > btw, the better solution here is to wait until the guest is ready for timer interrupt injection again, but that's not as easy as arming a timer. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic.