
<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div></div><div><br></div><div>On 21 Jan 2017, at 07:42, Kuan Hsun Chen <<a href="mailto:kuan-hsun.chen@tu-dortmund.de">kuan-hsun.chen@tu-dortmund.de</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr">Hi Tianyang,<div><br></div>I am interested to the overrun handling problem as well.<div>No matter which scheduler you use in LitmusRT, when a job is finished and calling job_completion(), prepare_for_next_period() will be called. </div><div>By digging into this function, you can see that setup_release() will update job sequence number, i.e., job_no. </div><div>This number will be checked in sys_wait_for_job_release() in litmus.c. </div></div></div></blockquote><div><br></div><div>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".</div><div><br></div><div>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.</div><br><blockquote type="cite"><div><div dir="ltr"><div>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".</div><div>The idea here is to check if the current job is the exact the last ready job of this task. <br></div>The task is only going to sleep only when its # of released job is larger than job_no by triggering complete_job().</div></div></blockquote><div><br></div><div>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... </div><br><blockquote type="cite"><div><div dir="ltr"><div><div>Therefore, those postponed jobs will be released still until the condition holds, and your first problem is somehow not existed. Am I right?</div><div><br></div><div>About your second question, I find that job_completion() is defined differently in pfp and edf, i.e., sched_trace_task_release<wbr>(t) is not called in edf<span style="color:rgb(51,51,51);font-family:consolas,"liberation mono",menlo,courier,monospace;font-size:12px;white-space:pre-wrap">.</span></div><div>I'm not sure if it is related :P</div></div></div></div></blockquote><div><br></div><div>Probably an oversight. Patches welcome.</div><div><br></div><div>- Björn </div><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra">

</div></div>

</div></blockquote></body></html>