From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1Ky8fB-0000Um-80
	for qemu-devel@nongnu.org; Thu, 06 Nov 2008 12:28:57 -0500
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1Ky8f9-0000Sn-F1
	for qemu-devel@nongnu.org; Thu, 06 Nov 2008 12:28:56 -0500
Received: from [199.232.76.173] (port=59338 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1Ky8f9-0000Sc-6g
	for qemu-devel@nongnu.org; Thu, 06 Nov 2008 12:28:55 -0500
Received: from sj-iport-2.cisco.com ([171.71.176.71]:4231)
	by monty-python.gnu.org with esmtps (TLS-1.0:RSA_ARCFOUR_SHA1:16)
	(Exim 4.60) (envelope-from <daahern@cisco.com>) id 1Ky8f9-0003Vx-9D
	for qemu-devel@nongnu.org; Thu, 06 Nov 2008 12:28:55 -0500
Message-ID: <4913294C.3040105@cisco.com>
Date: Thu, 06 Nov 2008 10:28:44 -0700
From: "David S. Ahern" <daahern@cisco.com>
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>
	<49119551.2070704@redhat.com>
In-Reply-To: <49119551.2070704@redhat.com>
Content-Type: text/plain; charset=windows-1255
Content-Transfer-Encoding: 7bit
Reply-To: qemu-devel@nongnu.org
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: gleb@redhat.com
Cc: qemu-devel@nongnu.org



Dor Laor wrote:
> Gleb Natapov wrote:
>> On Fri, Oct 31, 2008 at 02:17:19PM -0500, Anthony Liguori wrote:
>>   
>>> Gleb Natapov wrote:
>>>     
>>>> Qemu device emulation for timers might be inaccurate and
>>>> causes coalescing of several IRQs into one. It happens when the
>>>> load on the host is high and the guest did not manage to ack the
>>>> previous IRQ. The problem can be reproduced by copying of a big
>>>> file or many small ones inside Windows guest. When you do that guest 
>>>> clock start to lag behind the host one.

<snip>

>>
>>   
>>>                                                                 How do  
>>> Linux guests behave with this?
>>>     
>> Linux guests don't use pit or RTC for time keeping. They are completely
>> unaffected by those patches.
>>
>>   
> It will probably also drift with clock=pit in the guest kernel cmdline.

It is my understanding that for linux guests using a 2.4 kernel (e.g.,
RHEL3) the PIT is the only option.

david