[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



I guess another alternative is missed.
We need to add 3rd choice to ignore pending_intr_nr for X64 Linux.

thx,eddie

>-----Original Message-----
>From: Keir Fraser [mailto:Keir.Fraser@xxxxxxxxxxxx] 
>Sent: 2007年10月30日 1:30
>To: Dave Winchell; Dong, Eddie
>Cc: xen-devel; Ben Guthro; Shan, Haitao
>Subject: Re: [Xen-devel] [PATCH] Fix hvm guest time to be more accurate
>
>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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.