User talk:Billhuey
From RTwiki
(Difference between revisions)
(→Grand Unified Scheduler Project + QoS) |
(→Grand Unified Scheduler Project + QoS) |
||
| Line 3: | Line 3: | ||
Questions I'm pondering: | Questions I'm pondering: | ||
| − | <b>EDF</b> = earliest deadline first | + | *<b>EDF</b> = earliest deadline first |
| − | <b>HRT</b> = hard real time<br> | + | *<b>HRT</b> = hard real time<br> |
| − | <b>SRT</b> = soft real time<br> | + | *<b>SRT</b> = soft real time<br> |
| − | <b>BE</b> = best effort<br> | + | *<b>BE</b> = best effort<br> |
| − | Policies: | + | ====Policies:==== |
| − | SCHED_FIFO: | + | =====SCHED_FIFO:===== |
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. | 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. | ||
| − | SCHED_RR: | + | =====SCHED_RR:===== |
Cyclic/periodic in nature. | Cyclic/periodic in nature. | ||
Revision as of 09:29, 27 March 2008
Contents |
Grand Unified Scheduler Project + QoS
Questions I'm pondering:
- EDF = earliest deadline first
- HRT = hard real time
- SRT = soft real time
- BE = best effort
Policies:
SCHED_FIFO:
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.
SCHED_RR:
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.
- 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 ?
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 ?
...
