[LITMUS^RT] arm_release_timer

[ayoade gbadebo]

thanks


On Wed, Feb 26, 2014 at 4:36 PM, Glenn Elliott <gelliott at cs.unc.edu> wrote:

>
> On Feb 26, 2014, at 5:09 PM, ayoade gbadebo <gbaduz at gmail.com> wrote:
>
>
> Please I need explanation on how arm_release_timer_on() works with ready
> queue and release queue to make sure jobs are released to run periodically.
>
> And also can this phrase be explained as shown in the plugin tutorial
>
> "The preemption check callback is invoked by the rt_domain_t 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 rt_domain_t code, the calling thread already holds the
> ready queue lock."
>
> In summary, who keeps check of when to actually rerun a job on the cpu? Is
> this ensured by the arm_release_timer.
>
>
> Litmus does some complicated things to make releases efficient.  Here's
> how it works at a high level:
> 1) Job executes
> 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".
> 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.
> 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.
>
> 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:
> http://www.cs.unc.edu/~anderson/papers/rtss09a.pdf
>
> -Glenn
>
> _______________________________________________
> litmus-dev mailing list
> litmus-dev at lists.litmus-rt.org
> https://lists.litmus-rt.org/listinfo/litmus-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.litmus-rt.org/pipermail/litmus-dev/attachments/20140226/8802b6d3/attachment.html>