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] Add a timer mode that disables pending missed ti

To: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>, Dave Winchell <dwinchell@xxxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH] Add a timer mode that disables pending missed ticks
From: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Date: Fri, 02 Nov 2007 16:35:37 +0000
Cc: "Shan, Haitao" <haitao.shan@xxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx, "Dong, Eddie" <eddie.dong@xxxxxxxxx>, "Jiang, Yunhong" <yunhong.jiang@xxxxxxxxx>
Delivery-date: Fri, 02 Nov 2007 09:36:35 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <C350FD7A.17DB6%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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Acgda35vvPhR94leEdyrMQAX8io7RQAAudHU
Thread-topic: [Xen-devel] [PATCH] Add a timer mode that disables pending missed ticks
User-agent: Microsoft-Entourage/11.3.6.070618
By the way I checked in the other bits we agree on as changeset 16312. It
now looks quite sane to me.

 -- Keir

On 2/11/07 16:14, "Keir Fraser" <Keir.Fraser@xxxxxxxxxxxx> wrote:

> Thanks for the explanation. I think you are mis-describing the current
> behaviour of vpt.c though (If I understand it correctly myself, which I may
> not!). As I understand it, we do *not* unconditionally deliver a tick and
> reset the time space when a vcpu is scheduled onto a cpu. We only do that if
> (NOW() - pt->scheduled) >= 0 -- that is if more than a tick period has
> passed. Otherwise we wait to deliver the next tick exactly one period after
> the previous tick was delivered. The remainder of your explanation seems to
> be predicated on the (impossible?) case that we deliver a tick less than one
> period after the previous one.
> 
> Am I confused? :-) Also, what version of Linux are we talking about here,
> and what periodic timer, and x86/64 or i386? There are lots of different
> Linux timer-handling logics out there in the wild!
> 
>  -- Keir
> 
> On 2/11/07 15:51, "Dave Winchell" <dwinchell@xxxxxxxxxxxxxxx> wrote:
> 
>> Let D be the time that the clock vcpu is descheduled and P be
>> the clock period.  When D < P, I think there is an issue.
>> 
>> The reason is that Linux's offset calculation, which affects the
>> last clock interrupt tsc that is recorded, doesn't kick in if the
>> time since the last interrupt is less than P. In this case it sets
>> offset to zero. Linux records the tsc of the current (last) clock interrupt
>> as (current tsc - offset).
>> 
>> Interrupt delivery method AS delivers a clock interrupt
>> at context switch (in) time. When D < P, Linux records the
>> interrupt delivery time as current tsc and bumps jiffies.
>> This results in a gain of time equal to P-D over wall time.
>> 
>> For method S this never happens because the interrupt isn't
>> delivered until the next boundary.
> 
> 
> 
> _______________________________________________
> 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