From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KxmQJ-00022i-ON for qemu-devel@nongnu.org; Wed, 05 Nov 2008 12:44:07 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KxmQI-000225-Ke for qemu-devel@nongnu.org; Wed, 05 Nov 2008 12:44:07 -0500 Received: from [199.232.76.173] (port=55555 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KxmQI-00021l-FY for qemu-devel@nongnu.org; Wed, 05 Nov 2008 12:44:06 -0500 Received: from mx2.redhat.com ([66.187.237.31]:54145) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KxmQH-0003EQ-Nd for qemu-devel@nongnu.org; Wed, 05 Nov 2008 12:44:06 -0500 Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26]) by mx2.redhat.com (8.13.8/8.13.8) with ESMTP id mA5HheUm028928 for ; Wed, 5 Nov 2008 12:43:40 -0500 Date: Wed, 5 Nov 2008 19:43:45 +0200 From: Gleb Natapov Subject: Re: [Qemu-devel] [RESEND][PATCH 0/3] Fix guest time drift under heavy load. Message-ID: <20081105174345.GB3820@redhat.com> References: <20081029152236.14831.15193.stgit@dhcp-1-237.local> <490B59BF.3000205@codemonkey.ws> <20081102130441.GD16809@redhat.com> <49119551.2070704@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49119551.2070704@redhat.com> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: dlaor@redhat.com, qemu-devel@nongnu.org On Wed, Nov 05, 2008 at 02:45:05PM +0200, Dor Laor wrote: >>> As I've said repeatedly in the past, any sort of time drift fixes >>> needs to have a lot of data posted with it that is repeatable. >>> >>> How much does this improve things with Windows? >> The time drift is eliminated. If there is a spike in a load time may >> slow down, but after that it catches up (this happens only during very >> high loads though). >> >> > Gleb, can you please provide more details: > - What's the host's kernel version exactly (including the high-res, dyn > tick configured) Kernel 2.6.25. Qemu uses dynticks (CLOCK_REALTIME) timer. But why high-res timers should help fix time-drift problem at all? Time drift happens because guest doesn't get enough time to run, if host timer will be more precise this will not magically provide guest with more CPU time to handle them. > - What's the windows version? Is it standard HAL (pit) or ACPI (rtc) or > both? In my case this what windows2003 with ACPI HAL. > - The detailed scenario you use (example: I copied the entire c:/windows > directory, etc) Just run one guest in qemu on otherwise un-loaded host and copy entire c:/windows directory somewhere. > - Without the patch, what the time drift after x seconds on the host. After 15 minutes time drift was 5 minutes. But this is with write through disk cache (default now). With write back cache situation is much better. After 5 minutes the drift was 8 secs. > - With the patch, is there a drift? Is there increased cpu consumption, etc There is no drift with the patch. CPU consumption is 100 with cache write back so it can be increased any more and with cache write through qemu doing mostly IO. I am sure that copying will take more time with the patch since more time interrupts will be handled by guest. -- Gleb.