WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

To: "Keir Fraser" <Keir.Fraser@xxxxxxxxxxxx>, "Dave Winchell" <dwinchell@xxxxxxxxxxxxxxx>
Subject: RE: [Xen-devel] [PATCH] Fix hvm guest time to be more accurate
From: "Dong, Eddie" <eddie.dong@xxxxxxxxx>
Date: Tue, 30 Oct 2007 19:45:15 +0800
Cc: xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, "Shan, Haitao" <haitao.shan@xxxxxxxxx>, Ben Guthro <bguthro@xxxxxxxxxxxxxxx>
Delivery-date: Tue, 30 Oct 2007 04:50:49 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <C34BC908.1795D%Keir.Fraser@xxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <4725F5A3.7070009@xxxxxxxxxxxxxxx> <C34BC908.1795D%Keir.Fraser@xxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcgaUUtqicj/MoZEEdyYhAAX8io7RQAmOpiQ
Thread-topic: [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