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

[Dave Winchell <dwinchell@xxxxxxxxxxxxxxx>]

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