Re: (progress on hpet accuracy) and Re: [Xen-devel] [PATCH] Add a timer mode that disables pending missed ticks

[Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>]

If this is an integration of hpet into the vpt.c infrastructure then that
would be very welcome.

 -- Keir

On 25/2/08 20:01, "Dave Winchell" <dwinchell@xxxxxxxxxxxxxxx> 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
>> 
>> 
>> 
>>  
>> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel