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>
Subject: Re: [Xen-devel] [PATCH] Add a timer mode that disables pending missed ticks
From: Dave Winchell <dwinchell@xxxxxxxxxxxxxxx>
Date: Fri, 02 Nov 2007 14:05:37 -0400
Cc: "Dong, Eddie" <eddie.dong@xxxxxxxxx>, Dave Winchell <dwinchell@xxxxxxxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx, "Shan, Haitao" <haitao.shan@xxxxxxxxx>, "Jiang, Yunhong" <yunhong.jiang@xxxxxxxxx>
Delivery-date: Mon, 19 Nov 2007 10:16:01 -0800
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>
References: <C350FD7A.17DB6%Keir.Fraser@xxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla Thunderbird 1.0.7-1.1.fc4 (X11/20050929)
oops, you're right. I missed the  ( (NOW() - pt->scheduled) >= 0 ).

This means I will have to come up with another explanation.

-Dave


Keir Fraser 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

<Prev in Thread] Current Thread [Next in Thread>