User talk:Billhuey

From RTwiki
(Difference between revisions)
Jump to: navigation, search
(Grand Unified Scheduler Project)
(Grand Unified Scheduler Project)
Line 2: Line 2:
  
 
Questions I'm pondering:
 
Questions I'm pondering:
 +
 +
HRT = hard real time<br>
 +
SRT = soft real time<br>
 +
BE = best effort<br>
  
 
# 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 during a cross processor run queue scan to find a suitable time to handle an overload migration ? Let's call this EDF overload (rebalancing).
+
# 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 during a cross processor run queue scan to find a suitable BE slot span to handle an overload 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 ?
 
# 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:50, 27 March 2008

Grand Unified Scheduler Project

Questions I'm pondering:

HRT = hard real time
SRT = soft real time
BE = best effort

  1. 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 ?
  2. 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 ?
  3. 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 during a cross processor run queue scan to find a suitable BE slot span to handle an overload migration ? Let's call this EDF overload (rebalancing).
  4. How cheap is it to compute or pre-compute a span of slack slots for BE threads like irq-threads ?
  5. 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 ?
Personal tools