Re: [Xen-devel] [PATCH] Fix hvm guest time to be more accurate

[Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>]

I thought the point of the mode in Haitao's patch was to still deliver the
'right' number of pending interrupts, but not stall the guest TSC while
delivering them? That's what I checked in as c/s 16237 (in staging tree). If
we want other modes too they can be added to the enumeration that c/s
defines.

 -- Keir

On 29/10/07 15:00, "Dave Winchell" <dwinchell@xxxxxxxxxxxxxxx> wrote:

> Eddie, Haitao:
> 
> The patch looks good with the following comments.
> 
> 1. Since you are in missed_ticks(), why not increase the threshold
>     to 10 sec?
> 
> 2. In missed_ticks() you should only increment pending_intr_nr by
> missed_ticks
>     calculated when  pt_support_time_frozen(domain).
> 
> 3. You might as well fix this one too since its what we discussed and is so
>     related to constant tsc offset:
>       In pt_timer_fn, if !pt_support_time_frozen(domain) then
>       pending_intr_nr should end up with a maximum value of one.
> 
> regards,
> Dave
> 
> 
> Dong, Eddie wrote:
> 
>> Dave Winchell wrote:
>>  
>> 
>>> Eddie,
>>> 
>>> I implemented #2B and ran a three hour test
>>> with sles9-64 and rh4u4-64 guests. Each guest had 8 vcpus
>>> and the box was Intel with 2 physical processors.
>>> The guests were running large loads.
>>> Clock was pit. This is my usual test setup, except that I just
>>> as often used AMD nodes with more processors.
>>> 
>>> The time error was .02%, good enough for ntpd.
>>> 
>>> The implementation keeps a constant guest tsc offset.
>>> There is no pending_nr cancellation.
>>> When the vpt.c timer expires, it only increments pending_nr
>>> if its value is zero.
>>> Missed_ticks() is still calculated, but only to update the new
>>> timeout value. There is no adjustment to the tsc offset
>>> (set_guest_time())
>>> at clock interrupt delivery time nor at re-scheduling time.
>>> 
>>> So, I like this method better than the pending_nr subtract.
>>> I'm going to work on this some more and, if all goes well,
>>> propose a new code submission soon.
>>> I'll put some kind of policy switch in too, which we can discuss
>>> and modify, but it will be along the lines of what we discussed below.
>>> 
>>> Thanks for your input!
>>> 
>>> -Dave
>>> 
>>>    
>>> 
>> 
>> 
>> Haitao Shai may posted his patch, can u check if there are something
>> missed?
>> thx,eddie
>>  
>> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel



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