From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dave Winchell Subject: Re: [PATCH] Add a timer mode that disables pending missed ticks Date: Fri, 02 Nov 2007 14:05:37 -0400 Message-ID: <472B66F1.20201@virtualiron.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Keir Fraser Cc: "Dong, Eddie" , Dave Winchell , xen-devel@lists.xensource.com, "Shan, Haitao" , "Jiang, Yunhong" List-Id: xen-devel@lists.xenproject.org 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" 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. >> >> > > > >