User: Password:
Subscribe / Log in / New account

The IRMOS realtime scheduler

The IRMOS realtime scheduler

Posted Aug 4, 2010 19:29 UTC (Wed) by tcucinotta (guest, #69261)
In reply to: The IRMOS realtime scheduler by alison
Parent article: The IRMOS realtime scheduler

AFAIU, you are referring to the problem of how exactly to choose proper scheduling parameters in order to have a complex real-time application meet all of its deadlines, and what is an exact admission control scheme that ensures that all of the reserved tasks (or task groups) are granted their reserved resources (in presence of possible deadlines different from the periods, blocking times, offsets, non-preemptible sections, etc.).
These two problems need to be tackled similarly when using SCHED_DEADLINE and the IRMOS scheduler: one needs to use proper (and complex) analysis techniques in order to make a strong assessment about the capability of the system to have all real-time applications respect their timing constraints. That said, it is always possible to take simplified approaches, like requesting to the kernel an allocation with period equal to the WCET + max-blocking-time, and period equal to the minimum between the relative deadline and the minimum job inter-arrival time. More complex and precise admission control algorithms may be prohibitive for being coded in the kernel, however some user-space middleware (daemon + application library) might implement them.
The hierarchical scheduling capability of the IRMOS scheduler implies only a little difference w.r.t. the mentioned problem: if an application (or software component) is built of multiple tasks that need a scheduling guarantee as a whole, then the IRMOS scheduler allows for doing that, defining one single reservation with inside all the tasks (where the exact scheduling may still be fine-tuned by using different priorities if needed), whilst SCHED_DEADLINE would force one to use one reservation for each different task, with an increased "fragmentation" of the allocated CPU time and the little risk of having more bandwidth waste due to the need for the necessary over-provisioning. For example, in a recent modification to Jack (, we conveniently exploited such hierarchical feature by forcing all of the audio real-time (jack client) threads from the various multimedia processes into the same reservation, because the entire audio-processing pipeline needs to complete anyway within the next audio cycle.

(Log in to post comments)

The IRMOS realtime scheduler

Posted Aug 8, 2010 18:38 UTC (Sun) by naptastic (guest, #60139) [Link]

"...we conveniently exploited such hierarchical feature by forcing all of the audio real-time (jack client) threads from the various multimedia processes into the same reservation..."

How well did that work?

The IRMOS realtime scheduler

Posted Aug 9, 2010 8:02 UTC (Mon) by tcucinotta (guest, #69261) [Link]

Quite well. Of course, nothing can work better than using the PC for doing exclusively (jack-enabled) audio, with jack (and client threads) running at real-time priority, with rt-priorities fine-tuned by hand (e.g., see or, in case of more real-time applications, employing a rate-monotonic ordering), etc.

However, the interesting facts I can point out are the following:

1) the obtained Jack "driver end times" are basically similar to the ones of the configuration above, detailing:
1.a) when using soft resource reservations, we actually got similar driver end times with no xrun events;
1.b) when using hard resource reservations, a few jack xrun might occur in correspondence of abrupt workload changes (e.g., a software synthesizer) -- this is expected due to 2.b), and it can be mitigated by increasing the over-provisioning level;

2) the modified Jack (daemon and library) finds automatically the needed scheduling parameters and requires no modifications to the applications:
2.a) the period is set depending on the configured sampling frequency and buffer size;
2.b) the budget is dynamically adapted following the monitored workload, with a few heuristics for: providing a proper safety over-provisioning level, reacting to new jack clients registration, and reacting to xrun occurrence;

3) in presence of other real-time applications on the system, the achieved performance of both Jack and the other real-time applications (exploiting EDF-based scheduling with temporal isolation) can be investigated in isolation, and no cumbersome (for the end-user) priority tuning is needed.

Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds