[LITMUS^RT] Deadline and release miss in EDF

[Björn Brandenburg]

> On 21 Jan 2017, at 07:42, Kuan Hsun Chen <kuan-hsun.chen at tu-dortmund.de> wrote:
> 
> Hi Tianyang,
> 
> I am interested to the overrun handling problem as well.
> No matter which scheduler you use in LitmusRT, when a job is finished and calling job_completion(), prepare_for_next_period() will be called. 
> By digging into this function, you can see that setup_release() will update job sequence number, i.e., job_no. 
> This number will be checked in sys_wait_for_job_release() in litmus.c. 

Yes, but I don't recommend to rely on this interface for new code. It is sort of "legacy code" and not very flexible. As I said in my other mail, the notion of "job" in the kernel really means "budget instance" and may not have much to do with the application's idea of a "job".

For precise control over when jobs are activated, use clock_nanosleep() and the CLOCK_MONOTONIC clock source. This also works well with the first-class reservations implemented in P-RES.

> As we can read in the comment, "If the last job overran, then job <= job_no and we don't send the task to sleep".
> The idea here is to check if the current job is the exact the last ready job of this task. 
> The task is only going to sleep only when its # of released job is larger than job_no by triggering complete_job().

The whole interface is a bit brittle. It served our needs at the time, but in hindsight I would not add it to the kernel again. We should probably refactor LITMUS^RT at some point to get rid of it... 

> Therefore, those postponed jobs will be released still until the condition holds, and your first problem is somehow not existed. Am I right?
> 
> About your second question, I find that job_completion() is defined differently in pfp and edf, i.e., sched_trace_task_release(t) is not called in edf.
> I'm not sure if it is related :P

Probably an oversight. Patches welcome.

- Björn 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.litmus-rt.org/pipermail/litmus-dev/attachments/20170121/553a2e56/attachment.html>