lkml.org 
[lkml]   [2008]   [Oct]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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


\
 
 \ /
  Last update: 2008-10-23 03:07    [W:0.209 / U:0.384 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site