Messages in this thread | | | Date | Wed, 22 Oct 2008 21:05:07 -0400 | From | "Daniel Rosenthal" <> | Subject | Re: behavior of hrtimers scheduled to expire in the past, SCHED_SPORADIC subtlety |
| |
On Tue, Oct 21, 2008 at 4:09 AM, Thomas Gleixner <tglx@linutronix.de> wrote: > On Mon, 20 Oct 2008, Daniel Rosenthal wrote: >> What is the intended behavior for an hrtimer that is scheduled to >> expire in the past? I assumed that it would simply be scheduled to >> expire at the nearest available time in the future, but I wrote some >> scheduler code and it looks like hrtimers don't go off at all if they >> are not scheduled to go off at a time which is after rq->clock. Is >> this the intended behavior or is this a bug? > > That depends on the callback mode of the hrtimer. The standard ones > are scheduled to the softirq when they are already expired, but those > which are not allowed to run their callback in softirq context are > _not_ enqueued and the caller has to check, whether the timer is > active/enqueued after starting it.
Ok, thanks for the heads up. Is this documented somewhere, or do I need to submit a patch?
Darrio, Just to warn you, be careful that your SCHED_SPORADIC implementation deals with the above situation correctly. There are situations in which the actual scheduling of a replenishment can unintentionally be deferred for an excessive period of time (i.e. a SCHED_SPORADIC task running at its high priority gets preempted for a relatively long time, or at least a time which is long compared to the task's period). In this case, you may accidentally end up scheduling a replenishment timer with an expiration time in the past (because (activation_time + period) < rq->clock ). Be careful to avoid this in your code because this is subtle and it took me a very long time to debug this (this was compounded by the fact that I made an incorrect assumption about hrtimers, discussed above). It can be solved by executing such past replenishments immediately, rather than submitting them to hrtimer_start().
And regarding SCHED_SPORADIC, I am also working on SCHED_SPORADIC in 2.6.25. If I don't finish my RFC patch by the time you finish your final 2.6.27 patch, please let me know because I believe it would be beneficial for us to compare code before any final decisions are made (mine still isn't working well enough to compare yet).
Daniel
| |