From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Ky6zZ-0006Wu-8x for qemu-devel@nongnu.org; Thu, 06 Nov 2008 10:41:53 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Ky6zX-0006Vt-LA for qemu-devel@nongnu.org; Thu, 06 Nov 2008 10:41:52 -0500 Received: from [199.232.76.173] (port=53926 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ky6zX-0006Vg-BS for qemu-devel@nongnu.org; Thu, 06 Nov 2008 10:41:51 -0500 Received: from qw-out-1920.google.com ([74.125.92.147]:10872) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Ky6zX-0005iX-8T for qemu-devel@nongnu.org; Thu, 06 Nov 2008 10:41:51 -0500 Received: by qw-out-1920.google.com with SMTP id 5so475362qwc.4 for ; Thu, 06 Nov 2008 07:41:49 -0800 (PST) Message-ID: <4913103A.2080002@codemonkey.ws> Date: Thu, 06 Nov 2008 09:41:46 -0600 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] [RESEND][PATCH 0/3] Fix guest time drift under heavy load. References: <490B59BF.3000205@codemonkey.ws> <20081102130441.GD16809@redhat.com> <49119551.2070704@redhat.com> <20081106071624.GC3820@redhat.com> <20081106100821.GF3820@redhat.com> <20081106141821.GG3820@redhat.com> <20081106150445.GB29861@redhat.com> In-Reply-To: <20081106150445.GB29861@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: qemu-devel@nongnu.org Cc: dlaor@redhat.com Gleb Natapov wrote: > On Thu, Nov 06, 2008 at 03:35:16PM +0100, andrzej zaborowski wrote: > >> >> We're talking about emulating the hw. We have to make compromises >> sometimes, but we try to avoid them. >> >> > Fair enough. Can we compromise in this case :) > We have work ahead of us to determine how much of a problem this really is. My suspicion is that we're going to discover that it's pretty difficult to produce noticable drift when using hosts with high resolution timers. I think we'll also find that it's relatively easy to produce drift on older hosts. If that's the case, I don't think anything that's very invasive is going to be acceptable because of diminishing returns. I think that a well isolated, optional work around that's enabled only on hosts that lack high resolution timers will probably be the solution. Regards, Anthony Liguori > -- > Gleb. > > >