[LITMUS^RT] Deadline Miss Behavior

Robert Gifford rgif at seas.upenn.edu
Wed Feb 24 02:14:08 CET 2021


Good Evening,

My name is Robert, I'm a graduate student using LITMUS-RT to schedule my
own real-time tasks for an experimental platform. I had a quick question on
LITMUS's behaviour when a job misses its deadline and budget enforcement is
enabled.

Some very quick background context:
Each of my real-time tasks is implemented using your great native C API for
switching the task over from the Linux background scheduler to our own
scheduling plugin. After releasing the task, we have a loop that executes
the workload for each new job release, as recommended by your
documentation, sleeping until the next release at the end of each loop.
Running some tests and looking through the kernel code, it appears that if
the job were to miss its deadline, it would be preempted by the scheduler,
log the job as having missed its deadline, and prepare the scheduler for
the next immediate release while the user level task itself stays
unaffected. When the next job is scheduled, the application resumes from
where it was previously preempted, even though the kernel considers it a
new job.

Is there a way to handle resetting the user level application from the top
of the job's loop instead of having the next job resume from where the last
one left off? It is important for us that each new job starts from the
beginning. This seemed like a common scenario for hard real-time
applications and I wasn't sure if I was missing something.
I imagine that a difficult part of handling this is ensuring that the state
of the task's memory is consistent for each new job release and I don't
know how the kernel would be able to handle resetting this for any generic
application.
Thank you for your time as well as any and all assistance!

Best,
Robert
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.litmus-rt.org/pipermail/litmus-dev/attachments/20210223/2ee724d1/attachment.html>


More information about the litmus-dev mailing list