Grand Unified Scheduler Project + QoS
Glossary of terms
EDF = earliest deadline first
HRT = hard real time
SRT = soft real time
BE = best effort
Can be used (1) as a hard real time policy, but also be (2) used as a way of getting minimal lag to service a burt of events like interrupts.
Cyclic/periodic in nature.
- How does a static priority system like Linux express itself in terms of an EDF scheduler ? This potentially complicated because of non-standard real time uses of real time policies. How do things like hardness in a SCHED_FIFO task map to in EDF ? How does SCHED_RR map onto EDF ? For a special performance driven BE burst case of use of SCHED_FIFO, a lagging or differing is not considered a failure, how is that mapped onto EDF ? This isn't considered a failure for this use the policy.
There is a recent paper from UNC-CH on creating a unified framework for static and dynamic priorities. Basic idea is to have a priority of a task or a job to be expressed as a single number X, and thus decouple timing constraint (the actual deadline) from how jobs are prioritized.
Suppose you have three tasks T1, T2, T3 and each task submits jobs repeatedly. Under EDF, jobs are prioritized by their deadlines X_i=j*p, where p is the period of the task. If we conisder a static-priority scheme, jobs of T1 have priority X_1=1, jobs of T2 have priority X_2=2, and jobs of T3 have priority X_3=3. So if we select a job with the smallest value of priority jobs of T1 will be favored over those of T2 and T3. Think of static priority as of EDF with constant deadline. It is also possible to describe FIFO - jobs are just prioritized by their release times X_i=(j-1)*p (or equivalently - have same relative deadling). Some sort of fair policy is also possible to implement, as time progresses you just increase the value of priority X_i of currently running task by some amount. Priorities of sleeping tasks remain unchanged. At some point of time another task will have the minimum value of X_i. Though we did not analyze this sort of scheduling policy in details. Please read the paper The first three sections have many example schedules to give an idea of how this approach works.
- Is M-CASH, EDF-HSB etc... flexible enough as an abstract container or common factor mathematically or algorithmically so that all three stock scheduler policies, SCHED_FIFO, SCHED_RR and SCHED_OTHER (CFS) can be constructed in terms of that algorithm ?
- How would a practical EDF system look like with overload code ? Have EDF be largely run queue localized with manual assignments and with crude not-so-rigorous aperiodic overload handling (below) ?
- If these algorithms overlook the problem of aperiodic overloads, then what kind of crude not so rigorous overload handling can we do ? apply what we have already with the current rt-overload logic where we scan run queues across the system (or possibly with a specific CPU set) to migrate a task to another CPU that isn't running a real time task (SCHED_FIFO/RR) ? What about the use of a cheaply precomputed slack span that can be quickly read during a cross processor run queue scan for finding a suitable BE slot span to handle an overload migration with near future soft deadline ? Let's call this EDF overload (rebalancing).
- How cheap is it to compute or pre-compute a span of slack slots for BE threads like irq-threads ?
- Localize slack computation so that we can bypass the use of a global EDF computation if possible for certain aperiodic tasks.
QoS (Quality of Service)
- Do we need EDF for QoS ? Or should we just used special manually tuned IO handling daemon servers to issue requests in terms of bandwidth ? It would construct its scheduling policy statically and/or dynamically in a custom manner with SCHED_FIFO.
- How much CPU time is need to handle a single interrupt ? can this be used as a center piece for an EDF algorithm to use to help pre-compute a BE span ?
mplayer + SCHED_RR + /dev/rtc emulation using timerfd
- [done] lock analysis of the timerfd paths, Posix locking code, etc... [It doesn't really hit locks for file descriptors that are backed with an anonymous inode]
-  think about getting SCHED_RR to be driven by a VBL interrupt and phase lock loop it so that the period is precise and correct.
-  write a ld.so preload library to emulate /dev/rtc so that there can be multiple openings of /dev/rtc from the perspective of the system. /dev/rtc is normally a single open device.
-  think about migration of SCHED_RR tasks across CPUs and synchronization with a common the VBL across those processors.