From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dave Winchell Subject: Re: (progress on hpet accuracy) and Re: [PATCH] Add a timer mode that disables pending missed ticks Date: Tue, 26 Feb 2008 09:45:28 -0500 Message-ID: <47C42608.1090501@virtualiron.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Keir Fraser Cc: "dan.magenheimer@oracle.com" , "xen-devel@lists.xensource.com" , Deepak Patel , Dave Winchell List-Id: xen-devel@lists.xenproject.org Hi Keir - Keir Fraser wrote: >If this is an integration of hpet into the vpt.c infrastructure then that >would be very welcome. > > So far it is not, however I may head in that direction. Last night's test had an error of .065% on one guest so I still have some work to do. -Dave > -- Keir > >On 25/2/08 20:01, "Dave Winchell" wrote: > > > >>Hi Dan, >> >>I've added a few comments below ... >> >>Lately I've been busy getting the hpet emulation to be accurate. >>Right now I have the hpet based clock error down to under .02% with >>a limited amount of testing. (The error was 1% or more before my changes.) >>I hope to submit a patch soon so others can try this out. I need to do more >>testing and reduce my changes to the minimal set required. >> >>One thing I really like about the hpet is that a test designed to see if >>the clock will go backwards passes on the hpet where it fails on >>the pit/tsc clock. I tried for quite a while to keep pit/tsc from going >>backwards, but was unsuccessful. It ended up being easier to fix the hpet >>emulation for accuracy. >> >>The clock going backwards test is simply a call to gettimeofday() in a loop, >>with no delay between calls except to check for new_time < prev_time. >>I run this from a driver calling do_gettimeofday() to make it >>more stressful. Then I run an instance of this on all (8) vcpus on >>8 physical * 2 guests for a total of 16 vcpus running the test. >>The test does a yield now and then so you can actually log into the >>system, etc. >> >>Regards, >>Dave >> >>Dan Magenheimer wrote: >> >> >> >>>Hi Dave -- >>> >>>I've looked into RHEL5-64 a bit more and would appreciate >>>any thoughts you might have: >>> >>> >>> >>> >>> >>>>>So, some open questions: >>>>>[2] In RHEL5, I *think* it is the WALL source that we care about? >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>I'll have to check on this too. >>>> >>>> >>>> >>>> >>>On second look, I may be wrong. The GTOD clock seems to be >>>the one associated with vxtime.mode and vxtime.mode is used in >>>linux-2.6.18.8/arch/x86_64/kernel/time.c:main_timer_handler() to >>>determine if a tick is lost or not. Is this the code that we >>>want timer_mode=2 to influence? >>> >>> >>> >>> >>Yes, it is. >> >> >> >>> >>> >>> >>> >>>>>[1] Is notsc necessary for proper ticks for RHEL4-32/RHEL5-64? >>>>> (I *think* not as it has never come up in any email.) >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>I have not investigated this yet. >>>> >>>> >>>> >>>> >>>Well for RHEL5-64, looking at linux-2.6.18.8/arch/x86_64/kernel/time.c, >>>it appears whether notsc is required or not depends in part on the >>>underlying virtual AND physical system. >>> >>>notsc definitely is involved in the selection of GTOD time >>>but notsc can get set not only by kernel command line parameter >>>but also by the result of unsynchronized_tsc(): >>> >>> >>> >>> >>According to the comment in time.c, unsynchronized_tsc() is guessing >>whether the tsc is synchronized across processors. On most physical >>platforms they are, >>and, on those physical platforms the virtualization layer will present the >>same error as the hardware exibits. Right now we don't have code in xen to >>make a unsynchronized host look synchronized to the guest, though that >>wouldn't be very hard to do as long as the error between physical processors >>remained constant. >> >> >> >>>if (apic_is_clustered_box) notsc=1 >>>if (box_is_Intel) { >>>/* C3 delay is worst case HW latency to enter/exit C3 state */ >>>if (C3 delay < 1000) notsc=1 >>>} >>>else { /* e.g. AMD */ >>>if (num_present_cpus() > 1) notsc=1 >>>} >>> >>>I'm not sure what constitutes a clustered HVM guest or how that >>>C3 state latency is determined under Xen, but its clear that the >>>clocksource can be influenced not only by what clock hardware is >>>present and command-line parameters but also by the physical CPU >>>and number of guest vcpus. >>> >>> >>> >>> >>I haven't looked into >> >> >> >>>Yuck! >>> >>>Thanks, >>>Dan >>> >>> >>> >>> >>> >>> >>> > > > >