[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH] Add a timer mode that disables pending missed ticks



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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.