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

[Dave Winchell <dwinchell@virtualiron.com>]

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@virtualiron.com> 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.
>>    
>>
>
>
>  
>