From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KyjMp-0007kx-8B for qemu-devel@nongnu.org; Sat, 08 Nov 2008 03:40:27 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KyjMo-0007kO-85 for qemu-devel@nongnu.org; Sat, 08 Nov 2008 03:40:26 -0500 Received: from [199.232.76.173] (port=40230 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KyjMn-0007kG-PA for qemu-devel@nongnu.org; Sat, 08 Nov 2008 03:40:25 -0500 Received: from mx20.gnu.org ([199.232.41.8]:19982) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1KyjMn-0007To-8s for qemu-devel@nongnu.org; Sat, 08 Nov 2008 03:40:25 -0500 Received: from mx2.redhat.com ([66.187.237.31]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KyjMm-0001w0-Bn for qemu-devel@nongnu.org; Sat, 08 Nov 2008 03:40:24 -0500 Date: Sat, 8 Nov 2008 10:36:20 +0200 From: Gleb Natapov Subject: Re: [Qemu-devel] [RESEND][PATCH 0/3] Fix guest time drift under heavy load. Message-ID: <20081108083620.GB19381@redhat.com> References: <20081029152236.14831.15193.stgit@dhcp-1-237.local> <20081106081206.GD3820@redhat.com> <4912FAE5.9010100@codemonkey.ws> <200811061424.43689.paul@codesourcery.com> <491301C9.40506@codemonkey.ws> <20081106145142.GA29861@redhat.com> <49130F54.4060907@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49130F54.4060907@codemonkey.ws> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Paul Brook , qemu-devel@nongnu.org On Thu, Nov 06, 2008 at 09:37:56AM -0600, Anthony Liguori wrote: > Gleb Natapov wrote: >> On Thu, Nov 06, 2008 at 08:40:09AM -0600, Anthony Liguori wrote: >> >> >>> Gleb: are you perhaps using a qcow2 file in conjunction with >>> -snapshot? >> I am using qcow2, but without -snapshot. >> > > Okay, you would still see this if your qcow2 is relatively small > compared to the possible size it could be. > > I totally believe that you could miss ticks from qcow2 metadata writing > even with 100hz clock especially since we're using O_SYNC. A relatively > large write that has to extend the qcow2 file multiple times could > conceivably block the guest for more than 10ms. However, this is a bug > in qcow2 IMHO. Metadata updates should be done asynchronously and if > they did, I bet this problem wouldn't occur. A test against raw should > confirm this. > I ran the copy test once again with qcow2 image, but this time I copied from qcow2 to network fs and the drift still exists. Much smaller though. 8 second per hour AFAIR. >> >>>> If part of qemu gets swapped out then all bets are off, and you can >>>> easily stall for significant fractions of a second. No amount of >>>> host high resolution time support will help you there. >>>> >>> Running a steady workload, you aren't going to be partially swapped. >>> >>> >> We want to oversubscribe host as much as possible, and workload will >> vary during a lifetime of the VMs. >> > > I understand that we want guest time behave even when we're > overcommitting the host CPU. > > However, let's make sure we understand exactly what's going on such that > we know precisely what we're fixing. I believe the file copy benchmark > is going to turn out to no longer produce drift with a raw image. If > that's the case, you'll need to find another benchmark to quantify drift. > Yes indeed. With raw image copy benchmark no longer runs enough time to produce time drift big enough to be visible. So I ran this disk test utility http://69.90.47.6/mybootdisks.com/mybootdisks_com/nu2/bst514.zip for ~12 hours and the time drift was 12 secs (if I weren't so lazy and wrote bat file to copy c:\windows in a loop I am sure result would be the same). This is on completely idle host. > I think the best ones are going to be intense host workload (and let's > see how much is needed before we start drifting badly) and high guest > frequencies with hosts that lack high resolution timers. I think with a > high resolution guest and no host overcommit, it should be very > difficult to produce drift regardless of what the guest is doing. > Later I'll try to generate load on a host an see how this affects guest's time drift. -- Gleb.