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

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

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

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

Task Level Scheduling Example 0.2 0.4 0.6 0.8 1 20 40 60 80 100 27@f/3 47@f/2 26@f 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

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

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

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

Experiments (II) 100% is for Single voltage + Idle (NOP) Upper Bound 30 % 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

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