[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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |