User talk:Billhuey
From RTwiki
(Difference between revisions)
(New page: === Grand Unified Scheduler Project === Questions I'm pondering: # How does a static priority system like Linux express itself in terms of an EDF scheduler ? How do things like hardnes...) |
(→Grand Unified Scheduler Project) |
||
Line 1: | Line 1: | ||
− | |||
− | |||
=== Grand Unified Scheduler Project === | === Grand Unified Scheduler Project === | ||
Line 7: | Line 5: | ||
# How does a static priority system like Linux express itself in terms of an EDF scheduler ? How do things like hardness in a SCHED_FIFO task map to in EDF ? Some task are burst driven but lags or differing isn't considered a failure. How would a task like that be handled by EDF or variant ? | # How does a static priority system like Linux express itself in terms of an EDF scheduler ? How do things like hardness in a SCHED_FIFO task map to in EDF ? Some task are burst driven but lags or differing isn't considered a failure. How would a task like that be handled by EDF or variant ? | ||
# 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 ? | # 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 ? | ||
− | # If these algorithms overlook the problem of aperiodic overloads, then what kind of 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 so under an overload situation to help with migration ? | + | # If these algorithms overlook the problem of aperiodic overloads, then what kind of 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 so under an overload situation to help with migration ? 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 ? | # How cheap is it to compute or pre-compute a span of slack slots for BE threads like irq-threads ? | ||
+ | # How would a practical EDF system look like with overload code ? Have EDF be largely run queue localized with manual assignments and with an overload condition for softer jobs ? |
Revision as of 08:47, 27 March 2008
Grand Unified Scheduler Project
Questions I'm pondering:
- How does a static priority system like Linux express itself in terms of an EDF scheduler ? How do things like hardness in a SCHED_FIFO task map to in EDF ? Some task are burst driven but lags or differing isn't considered a failure. How would a task like that be handled by EDF or variant ?
- 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 ?
- If these algorithms overlook the problem of aperiodic overloads, then what kind of 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 so under an overload situation to help with migration ? 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 ?
- How would a practical EDF system look like with overload code ? Have EDF be largely run queue localized with manual assignments and with an overload condition for softer jobs ?