From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Ky5ZU-0001Jk-O7 for qemu-devel@nongnu.org; Thu, 06 Nov 2008 09:10:52 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Ky5ZU-0001JA-7W for qemu-devel@nongnu.org; Thu, 06 Nov 2008 09:10:52 -0500 Received: from [199.232.76.173] (port=43072 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ky5ZT-0001J0-Qh for qemu-devel@nongnu.org; Thu, 06 Nov 2008 09:10:51 -0500 Received: from ug-out-1314.google.com ([66.249.92.173]:39394) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Ky5ZT-0005Xm-7x for qemu-devel@nongnu.org; Thu, 06 Nov 2008 09:10:51 -0500 Received: by ug-out-1314.google.com with SMTP id 29so973312ugc.36 for ; Thu, 06 Nov 2008 06:10:48 -0800 (PST) Message-ID: <4912FAE5.9010100@codemonkey.ws> Date: Thu, 06 Nov 2008 08:10:45 -0600 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] [RESEND][PATCH 0/3] Fix guest time drift under heavy load. References: <20081029152236.14831.15193.stgit@dhcp-1-237.local> <490B59BF.3000205@codemonkey.ws> <20081102130441.GD16809@redhat.com> <4911CD42.2040803@codemonkey.ws> <20081106081206.GD3820@redhat.com> In-Reply-To: <20081106081206.GD3820@redhat.com> Content-Type: text/plain; charset=windows-1255; 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: Gleb Natapov Cc: qemu-devel@nongnu.org Gleb Natapov wrote: > On Wed, Nov 05, 2008 at 10:43:46AM -0600, Anthony Liguori wrote: > >> Gleb Natapov wrote: >> >> Sorry, I mistyped. I meant to say, I don't think any of the problems >> raised when this was initially posted have been addressed. Namely, I >> asked for hard data on how much this helped things >> > Does my answer to Dor's mail provide enough data? > I'll try to reproduce locally. Your case would be more compelling with a more thorough analysis but I can at least now attempt to determine how hr timers impacts this. >>>> How does having a >>>> high resolution timer in the host affect the problem to begin with? >>>> >>>> >>> My test machine has relatively recent kernel that use high resolution >>> timers for time keeping. Also the problem is that guest does not receive >>> enough time to process injected interrupt. How hr timer can help here? >>> >>> >> If the host can awaken QEMU 1024 times a second and QEMU can deliver a >> timer interrupt each time, there is no need for time drift fixing. >> >> > It is not enough to wake QEMU process 1024 time a second to signal time > interrupt. A guest should also have enough time to run between each > interrupt to process it. If QEMU signals 1024 time interrupt a second > and guest process only half of that a second you'll see time drift. > And if guest asks for 1024hz frequency and guest can't provide that no > solution for time drift exists in that case. > If nothing else is running on the system, the guest should get plenty of time to run timers. If the guest is not getting enough time on the system to be able to run their timer ticks, then coalescing the timer ticks isn't going to help by definition (they aren't getting enough CPU time to run these routines). >> I would think that with high res timers on the host, you would have to >> put the host under heavy load before drift began occurring. >> >> > I see a time drift even with guest using 100hz timers and I am pretty sure > my 2.6.25 host uses hr timers. > You see time drift with 100hz timers in the guest?? That makes very little sense as even without hr timers, the host should have no problem delivering a 10ms timer. Note, we just fixed an issue with delayed timer deliver. There may be more bugs like this that are causing ticks to get missed. If you have nothing else running on the host, no matter what you do in the guest, I see absolutely no reason why time should drift if the guest is running a 100hz timer. Do you have an explanation for this? >> The windows guest is supposed >> to be able to tell the hypervisor which technique it should be using. >> >> > Do you have pointer to a documentation that describe it? I am especially > interested if old guest like windows XP and windows 2003 support this? > Surprisingly many people are interested in those old guests, not shiny > newer ones :) > http://www.microsoft.com/downloads/details.aspx?FamilyID=91e2e518-c62c-4ff2-8e50-3a37ea4100f5&DisplayLang=en Regards, Anthony Liguori > -- > Gleb. >