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

[Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>]

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