<div dir="ltr">thanks</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Feb 26, 2014 at 4:36 PM, Glenn Elliott <span dir="ltr"><<a href="mailto:gelliott@cs.unc.edu" target="_blank">gelliott@cs.unc.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div class="h5"><br><div><div>On Feb 26, 2014, at 5:09 PM, ayoade gbadebo <<a href="mailto:gbaduz@gmail.com" target="_blank">gbaduz@gmail.com</a>> wrote:</div>
<br><blockquote type="cite"><div dir="ltr"><br><div>Please I need explanation on how <span style="white-space:pre-wrap">arm_release_timer_on() works with ready queue and release queue to make sure jobs are released to run periodically.</span></div>

<div><span style="white-space:pre-wrap"><br></span></div><div><span style="white-space:pre-wrap">And also can this phrase be explained as shown in the plugin tutorial</span></div><div><span style="white-space:pre-wrap"><br>

</span></div><div><span style="white-space:pre-wrap">"</span><span style="font-family:sans-serif;font-size:16px">The preemption check callback is invoked by the </span><tt>rt_domain_t</tt><span style="font-family:sans-serif;font-size:16px"> code whenever a job is transferred from the release queue to the ready queue (i.e., when a future release is processed). Since the callback is invoked from within the </span><tt>rt_domain_t</tt><span style="font-family:sans-serif;font-size:16px"> code, the calling thread already holds the ready queue lock.</span><span style="white-space:pre-wrap">"</span></div>

<div><span style="white-space:pre-wrap"><br></span></div><div><font><span style="white-space:pre-wrap">In summary, who keeps check of when to actually rerun a job on the cpu? Is this ensured by the arm_release_timer.</span></font></div>

</div></blockquote><br></div></div></div><div>Litmus does some complicated things to make releases efficient.  Here’s how it works at a high level:</div><div>1) Job executes</div><div>2) When the job calls sleep_next_period() or the job has exhausted its budget, Litmus computes the time when the next job should be released.  Let’s call this time “next_release”.</div>
<div>3) If current_time >= next_release, then the next job is already eligible to run.  Litmus recomputes the deadline of the next job if you’re using a deadline scheduler.  It then inserts the next job directly into the ready-queue.</div>
<div>4) If current_time < next_release, then the next job is put on the release-queue, and Litmus sets a timer to raise a timer interrupt at time next_release.  The timer is set using arm_release_timer() (or arm_release_timer_on() if you’ve compiled Litmus with CONFIG_RELEASE_MASTER).  At a later time when the timer interrupt is raised, Litmus moves all jobs in the release-queue with release times <= current_time to the ready-queue.</div>
<div><br></div><div>Note: Litmus uses high-resolution timers to track release times for all of its plugins.  However, you could conceivably write a plugin that checks the release-queue on every scheduler tick (every quantum).  I believe Björn may have explored this approach in this paper: <a href="http://www.cs.unc.edu/~anderson/papers/rtss09a.pdf" target="_blank">http://www.cs.unc.edu/~anderson/papers/rtss09a.pdf</a></div>
<span class="HOEnZb"><font color="#888888"><div><br></div><div>-Glenn</div></font></span></div><br>_______________________________________________<br>
litmus-dev mailing list<br>
<a href="mailto:litmus-dev@lists.litmus-rt.org">litmus-dev@lists.litmus-rt.org</a><br>
<a href="https://lists.litmus-rt.org/listinfo/litmus-dev" target="_blank">https://lists.litmus-rt.org/listinfo/litmus-dev</a><br>
<br></blockquote></div><br></div>