[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |