Re: behavior of hrtimers scheduled to expire in the past, SCHED_SPORADIC subtlety

[Daniel Rosenthal]

On Tue, Oct 21, 2008 at 4:09 AM, Thomas Gleixner <tglx@xxxxxxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/