From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1DQAXe-000402-Ue
	for qemu-devel@nongnu.org; Mon, 25 Apr 2005 16:50:55 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1DQAXd-0003zq-Ey
	for qemu-devel@nongnu.org; Mon, 25 Apr 2005 16:50:54 -0400
Received: from [199.232.76.173] (helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1DQAXd-0002nR-BF
	for qemu-devel@nongnu.org; Mon, 25 Apr 2005 16:50:53 -0400
Received: from [195.250.128.75] (helo=smtp2.vol.cz)
	by monty-python.gnu.org with esmtp
	(TLS-1.0:DHE_RSA_3DES_EDE_CBC_SHA:24) (Exim 4.34) id 1DQAPx-00024l-El
	for qemu-devel@nongnu.org; Mon, 25 Apr 2005 16:42:57 -0400
Received: from [10.0.0.2] (prg-v-6-220.static.adsl.vol.cz [62.177.70.220])
	by smtp2.vol.cz (8.12.9p2/8.12.9) with ESMTP id j3PKch8T036372
	for <qemu-devel@nongnu.org>; Mon, 25 Apr 2005 22:38:43 +0200 (CEST)
	(envelope-from navaraf@reactos.com)
Message-ID: <426D5552.4000104@reactos.com>
Date: Mon, 25 Apr 2005 22:38:42 +0200
From: Filip Navara <navaraf@reactos.com>
MIME-Version: 1.0
Subject: Re: [Qemu-devel] [patch] option -no-tsc for i386 with speedstep
References: <20050425111532.GA2554@dizzy.ath.cx>
	<426D3DBE.9080307@bellard.org>	<20050425201706.GA11602@dizzy.ath.cx>
	<380218305509284f15ded3ac17915cb1@elis.ugent.be>
In-Reply-To: <380218305509284f15ded3ac17915cb1@elis.ugent.be>
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: <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: qemu-devel@nongnu.org

Jonas Maebe wrote:

> On 25 Apr 2005, at 22:17, Massimo Dal Zotto wrote:
>
>> In the meantime until we find a better solution could you give us some
>> explanation on why using a microseconds clock from gettimeofday instead
>> of rdtsc the guest os clock runs always 20% slower?
>
> Because a system call (which gettimeofday is) is very slow (two 
> context switches).

I remember there was a Linux patch which changed the gettimeofday 
function to read the info from user mode shared page (which is updated 
by the kernel) and thus avoided the syscall overhead. Not sure if/when 
it was integrated into the official sources...

(Once again Windows NT were ahead of time with this idea implemented way 
earlier ;-)

- Filip