From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KzDHd-00031D-OQ for qemu-devel@nongnu.org; Sun, 09 Nov 2008 11:37:05 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KzDHc-00030Y-9Q for qemu-devel@nongnu.org; Sun, 09 Nov 2008 11:37:05 -0500 Received: from [199.232.76.173] (port=48917 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KzDHc-00030V-5E for qemu-devel@nongnu.org; Sun, 09 Nov 2008 11:37:04 -0500 Received: from rn-out-0910.google.com ([64.233.170.188]:20229) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KzDHb-0002MM-Vg for qemu-devel@nongnu.org; Sun, 09 Nov 2008 11:37:04 -0500 Received: by rn-out-0910.google.com with SMTP id m61so1510646rnd.8 for ; Sun, 09 Nov 2008 08:37:02 -0800 (PST) Message-ID: <491711AB.7000806@codemonkey.ws> Date: Sun, 09 Nov 2008 10:36:59 -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> <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> <20081108083620.GB19381@redhat.com> In-Reply-To: <20081108083620.GB19381@redhat.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: Gleb Natapov Cc: Paul Brook , qemu-devel@nongnu.org Gleb Natapov wrote: > On Thu, Nov 06, 2008 at 09:37:56AM -0600, Anthony Liguori wrote: > > > 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. > What frequency is the guest running at? If it's running at 100hz, then it missed a tick once every 36 seconds. This means that the guest couldn't run long enough to handle a timer interrupt (which should be a relatively small number of cycles) in a 10ms period. Does this drift go away with the TDF patches? This almost makes me think that we aren't delivering interrupts at the right frequency and we're simply accumulating error. In theory, the TDF patches shouldn't help that. Otherwise, I'm curious if you have any insight into where we're pausing for 10ms that's causing the missed interrupt? We could also be missing ticks somehow. I think this warrants further investigation. Regards, Anthony Liguori > >> 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. >