From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dor Laor Subject: Re: guest gettimeofday behavior Date: Sun, 28 Jun 2009 11:58:33 +0300 Message-ID: <4A4730B9.1090902@redhat.com> References: Reply-To: dlaor@redhat.com Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: kvm@vger.kernel.org To: Eran Rom Return-path: Received: from mx2.redhat.com ([66.187.237.31]:50902 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751673AbZF1I6L (ORCPT ); Sun, 28 Jun 2009 04:58:11 -0400 In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: On 06/25/2009 04:25 PM, Eran Rom wrote: > Hi All, > Am a newbie (to kvm, linux kernel, git, etc.) so apologize in advance for > missing/inaccurate info. > I am experiencing inconsistent behavior of guest gettimeofday, described below. > I have seen prior reference to the problem, however, it was not clear whether > the issue was solved or not and where. > > Below is a description of my setup and the behavior I see. > Another question is whether oprofile with timer mode would suffer from the same > problem? > > Otherwise I saw that kvm-85 has "generic performance counter msr handling", does > this mean that oprofile can be executed without the timer mode? > > Thanks very much, > Eran > > Setup: > Guest 32 bit ubuntu with 2.6.27 kernel > Host 64 bit Suse 10.2 with 2.6.27 kernel > 1 quadcore Intel Xeon CPU > I am not sure about the kvm userspace code version. > Used git to create a repository, and then did > git checkout kvm-updates-2.6.27 (is that fixed in time?) > > Behavior: > Running a code doing: > t1 = gettimeofday > t2 = gettimeofday > while t2-t1< 5 minutes { > sleep(1) > t2 = gettimeofday > } > > Ran it 10 times, each time in a 'newly launched' VM, halting it after the test. > 8 out of 10 times the wall clock showed 5 minutes > 1 time 4 minutes and 40 seconds > 1 time 0 seconds > I'm not sure what's your 'wall clock' value, there is not printf in your script. Nevertheless, the tsc clock is not reliable, the host can scale it, or go into deep sleep state. So either use newer kernel with kvmclock (pv) or change the clock source into rtc/pit > -- > To unsubscribe from this list: send the line "unsubscribe kvm" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html >