1. Flavius Gruian < flavius.gruian@cs.lth.se >
Hard Real-Time Scheduling for Low-Energy Using Stochastic Data and DVS Processors
Flavius Gruian < >
Embedded Systems Design
Laboratory
Lund Institute of Technology
Sweden
22/09/2018
ISLPED'01

2. Talk Outline Problem Definition Task Level Scheduling
Task-Set Scheduling
Offline
Online
Experiments
Conclusions
22/09/2018
ISLPED'01

3. Problem Definition Find an energy efficient scheduling policy for:
Systems with DVS processors
Trade speed for lower energy
Fixed priority RT-scheduling
(RM/DM)
Tasks with probabilistic behavior
Execution time between [BCE,WCE]
Sample characteristic of a
three supply voltage DVS processor
The problem we tackle is ”find energy efficient scheduling strategy”. And we’re talking about systems with dynamic voltage supply processors, where you can trade speed for low energy. As you know, for these types of processors one can change the supply voltage and clock frequency on the fly. As in this sample graph, high clock speed means high energy consumption.
We’re also talking about hard real-time tasks and fixed priority scheduling – for example rate or deadline monotonic.
Finally we’re considering tasks with probabilistic behavior, meaning they can take a variable time to complete their execution, time which can be between a best case and a worst case.
22/09/2018
ISLPED'01

4. Task Level Scheduling Basics
BCE
WCE X
WCE-stretch
BCE
WCE X
Ideal
BCE
WCE
deadline X
No scaling
BCE
WCE X
Stochastic
Stochastic schedule:
Accelerated execution
Minimize the energy in the long run
Use probability distribution function
On to task level scheduling. Without voltage scaling a task executes at the unique voltage, and finishes somewhere between best case and worst case. The processor becomes then idle.
[click] Ideally from the energy point of view, one should execute at that speed and voltage for which the task finishes exactly at the deadline. In practice one can only use the available voltages/clock speeds. Moreover, the exact execution time might not be known when the instance arrives.
[click] To make sure we always meet the deadline, we can assume that we will always execute the worst case and build a schedule using the available voltages. Let’s call this the Worst Case stretch schedule.
[click] A better scheduling strategy is obtained by taking into account the probabilistic behavior of the task. We present in the paper something called stochastic schedule, which reduces the energy consumption over a large number of instances. (…)
22/09/2018
ISLPED'01

5. Task Level Scheduling Example
0.2
0.4
0.6
0.8 1 20 40 60 80
100
Allowed is 200%
of WCE at clock f
1-cdf function for
a normal distribution
mean = 70 std. dev. = 10
1 - cdf
cycles
Obtaining a stochastic schedule for
a processor with clocks speeds f, f/2, f/3
80% of WCE cycles
100% of WCE cycles
Cycle energy
WCE at f
Mean = 70%
Such a stochastic schedule is obtained by using the execution time probability distribution of the task. More precisely the voltage schedule is correlated with the cummulative distribution function. This is an example of such a schedule – assuming we have a 3 voltage(or speeds) processor, and the task has a normal distribution. If the deadline twice longer than the worst case at the highest frewquency, the best schedule would be like this. First, when most instances are executing we run 27% of the cycles at f/3. The next 47% run at f/2. By the end of this portion the task instance will be finished in more than half the cases. Finally the last 26% cycles are run at the highest speed.
Compared to a worst case stretch schedule, the stochastic schedule can save quite a lot of energy, depending on the tasks characteristics/processors/deadline. A more detailed description of the stochastic schedule is given in the paper.
22/09/2018
ISLPED'01

6. Task Set Offline Scheduling
Use ”scheduling points analysis” [Lehoczky,Sha,Ding 89], [Shin&Choi 99]
Find a minimal required processor speed for which the deadlines are still met even for WCE
Different subsets - different minimal speeds
Consequences
Usually high priority tasks require higher speed
Processor utilization grows significanlty (most cases can do better than the worst case limit of 0.69)
That was task level scheduling method. Now on to the higher level of task set scheduling. First, in the offline phase we determine the minimal required clock speeds for each task. This is done using a schduling points analysis as introduced by Lehoczky Sha Ding in 89 and applied to DVS processors by Shin and Choi in 99. Instead of finding a unique required speed for all tasks, as Shin and Choi, we identify subsets with different required speeds.
By this in principle the high priority tasks will require higher processor speed than the low priority tasks. Also the processor utilization can grow signicantly. (most task sets can do much better than the worst case limit of 0.69 utilization)
22/09/2018
ISLPED'01

7. Task Set Online Scheduling
Remaining time slack from early finishing instances used to slow down future tasks.
Must keep Worst Case Response Time:
Use slack (priority) levels
A task instance:
Will use higher level slack
Will produce lower level slack
If there are no ready tasks, the running one to use all time to the next arrival [Shin&Choi99]
In the online phase, we can further reduce the execution speed for some instances by reusing the remainin slack resulted from early finishing tasks. Yet, since the worst case response time has to be kept, in order to meet the deadlines, this slack cannot be used in an arbitrary way. We employ levels of slack – corresponding to task priority levels. A task instance can only use higher level slack and genrates lower level slack. Moreover, the existent slack can be given all to one instance or proportionally distributed over all ready instances. A detailed description of the online algorithm is given in the paper. We also present an analysis of our policy which shows that all deadlines are met.
Finally, we also employ a technique first used by Shin and Choi – whenever a task is alone on the processor, it can use all the slack available till the next arrival of an instance.
22/09/2018
ISLPED'01

8. Experiments (I) Upper Bound: Ideal Stretch: Offline + 1 stretch: All:
Post execution analysis
– All instances are uniformly stretched
Ideal Stretch:
Actual execution times become known at arrival
Offline + 1 stretch:
”Lonely” instance stretched till next arrival
All:
Offline + online slack distribution + task level
But how much energy can be saved using all these techniques at task level and set level, offline and online? In the following you will see 4 curves describing the energy savings for 4 situations.
The Upper bound was obtained in a post execution analysis, where all instances were uniformly stretched to fill all the processor time. This is the absolute limit and can hardly be achieved in practice since deadlines might be violated, and execution times for the instances are most likely unknown.
The ideal stretch was obtained using our scheduling policy, but assuming that the exact execution time of an instance becomes known when the instance arrives (this is also an ideal scenario)
The offline plus one stretch is a scenario where no online slack distribution is used, except the one introduced by shin and choi in 99.
”All” is a scenario where both our offline and online policies are used, together with our stochastic task level schedule.
22/09/2018
ISLPED'01

9. Experiments (II) 100% is for Single voltage + Idle (NOP) Upper Bound30 %
40%
50%
60%
70%
80%
90%
100%
0.1
0.2
0.3
0.4
0.5
0.6
0.7
0.8
0.9 1
Offline+1stretch
All
Ideal stretch
Upper Bound
BCE/WCE
sets of 100 tasks
100% is for Single voltage +
Idle (NOP)
NOP power =
20% of mean
Power down =
5% of mean
Energy reduction
The graph presented here was obtained for task sets of 100 tasks with execution times spanning between a best case and a worst case according to a normal distribution. The horisontal axis describes the execution time distribution – starting left, the difference between the best and the worst case is big. This difference dicreases until best case almost overlaps with the worst case (meaning there is no variation in the task execution). On the vertical we have the energy reduction compared to the case when a single voltage is used. In idle the processor executes NOPs which consume 20% of the average power. [This is actually the experimental set-up from Shin and Choi’s paper]
As you can see, when all the policies are employed, we can get quite important reductions. On the extreme left, when the average case is almost half worst case – we can get up to 65% reductions. We actually always follow the upper bound within 25%.
More experiments are described in the paper, including two benchmarks, real life examples: an avionics application and a CNC controller.
22/09/2018
ISLPED'01

10. Conclusions Hard RT Systems can be energy efficient:
Use DVS processors
Use better scheduling policies
The presented scheduling approach:
Tasks with fixed priority
Both offline and online phases
Both at task level and task set level
Employs data about the stochastic behavior of the tasks to derive more efficient schedules
Finally to conclude:
Hard real-time systems can be made energy efficient if we use DVS processors and better scheduling policies.
The policy presented here targets fixed priority scheduling. It consists of both offline and online phases. Includes both task level and set level techniques. Moreover it employs data about the stochastic behavior of the tasks to derive more efficient schedules.
22/09/2018
ISLPED'01