2017/18 UniPD - T. Vardanega 10/03/2018
Standard notation
: Worst-case blocking time for the task (if applicable) 3.a Fixed-Priority Scheduling : Worst-case computation time (WCET) of the task ( ) : Relative deadline of the task : The interference time of the task : Release jitter of the task : Number of tasks in the system Credits to A. Burns and A. Wellings : Priority assigned to the task (if applicable) : Worst-case response time of the task : Minimum time between task releases, or task period ( ) : The utilization of each task ( ⁄ ) a-Z: The name of a task
2017/18 UniPD – T. Vardanega Real-Time Systems 168 of 515
The simplest workload model Fixed-priority scheduling (FPS)
The application is assumed to consist of tasks, for fixed At present, the most widely used approach in industry All tasks are periodic with known periods Each task has a fixed (static) priority determined off-line This defines the periodic workload model In real-time systems, the “priority” of a task is solely derived The tasks are completely independent of each other from its temporal requirements No contention for logical resources; no precedence constraints The task’s relative importance to the correct functioning of All tasks have a deadline equal to their period the system or its integrity is not a driving factor at this level A recent strand of research addresses mixed-criticality systems, with Each task must complete before it is next released scheduling solutions that contemplate criticality attributes All tasks have a single fixed WCET, which can be trusted as The ready tasks (jobs) are dispatched to execution in a safe and tight upper-bound the order determined by their (static) priority Operation modes are not considered Hence, in FPS, scheduling at run time is fully defined by the All system overheads (context-switch times, interrupt handling and so on) are assumed absorbed in the WCETs priority assignment algorithm
2017/18 UniPD – T. Vardanega Real-Time Systems 167 of 515 2017/18 UniPD – T. Vardanega Real-Time Systems 169 of 515
Real Time Systems 1 2017/18 UniPD - T. Vardanega 10/03/2018
Preemption and non-preemption /1 Rate-monotonic priority assignment
With priority-based scheduling, a high-priority task may be Each task is assigned a priority based on its period released during the execution of a lower priority one The shorter the period, the higher the priority In a preemptive scheme, there will be an immediate switch to Such priorities have to be unique: hence ties must be resolved the higher-priority task For any two tasks , : → With non-preemption, the lower-priority task will be allowed Rate monotonic assignment is optimal under preemptive to complete before the other may execute priority-based scheduling (and implicit deadlines) Preemptive schemes (such as FPS and EDF) enable higher- Nomenclature priority tasks to be more reactive, hence they are preferred Priority 1 as numerical value is the lowest (least) priority, but the indices are still sorted highest to lowest (!)
2017/18 UniPD – T. Vardanega Real-Time Systems 170 of 515 2017/18 UniPD – T. Vardanega Real-Time Systems 172 of 515
Preemption and non-preemption /2 Utilization-based test
Alternative strategies allow a lower priority task to continue A simple test exists for rate-monotonic scheduling executing for a bounded time before being preempted It provides a sufficient but not necessary upper-bound Such schemes use either deferred preemption or cooperative on the schedulable utilization of FPS dispatching Only for task sets with Value-based scheduling (VBS) is another approach to attenuating preemption Useful when the system becomes overloaded and some adaptive 2 1 scheme of scheduling is needed to mitigate the risk or the consequences of overrun VBS assigns a value to each task and then employs an on-line value- based scheduling algorithm to decide which task to run next lim 2 1 ln2 0.69 Analogous to usefulness, but determined off-line →
2017/18 UniPD – T. Vardanega Real-Time Systems 171 of 515 2017/18 UniPD – T. Vardanega Real-Time Systems 173 of 515
Real Time Systems 2 2017/18 UniPD - T. Vardanega 10/03/2018
Critique of utilization-based tests Timeline for task set A
Task These tests are sufficient but not necessary Task Release Time As such, they fall in the class of schedulability tests a Task Completion Time These tests are not exact and also not general Deadline Met b Task Completion Time But they are Ω , which makes them interesting Deadline Missed for some users c Preempted
Time Executing 0102030405060
2017/18 UniPD – T. Vardanega Real-Time Systems 174 of 515 2017/18 UniPD – T. Vardanega Real-Time Systems 176 of 515
Example: task set A Example: task set B
Task Period Computation Time Priority Utilization Task Period Computation Time Priority Utilization TC PU TC PU a5012 1 (low)0.24 a8032 1 (low)0.40 b 40 10 2 0.25 b 40 5 2 0.125 c 30 10 3 (high) 0.33 c 16 4 3 (high) 0.25
The combined utilization is 0.82 (or 82%) The combined utilization is 0.775 Above the threshold for three tasks (0.78) Below the threshold for three tasks (0.78) This task set fails the utilization test This task set passes the utilization test Hence we have no a-priori answer on its feasibility Hence this task set will meet all its deadlines
2017/18 UniPD – T. Vardanega Real-Time Systems 175 of 515 2017/18 UniPD – T. Vardanega Real-Time Systems 177 of 515
Real Time Systems 3 2017/18 UniPD - T. Vardanega 10/03/2018
Example: task set C Response time analysis /1
Task Period Computation Time Priority Utilization The worst-case response time of task is first TC PU calculated and then checked (trivially) with its a8040 1 (low)0.50 deadline b 40 10 2 0.25 is feasible iff c 20 5 3 (high) 0.25 , where is the interference that The combined utilization is 1.0 suffers from higher-priority tasks Above the threshold for three tasks (0.78) Again, this task set does not pass the utilization test Yet the timeline shows the task set will meet all its deadlines
2017/18 UniPD – T. Vardanega Real-Time Systems 178 of 515 2017/18 UniPD – T. Vardanega Real-Time Systems 180 of 515
Timeline for task set C Calculating R
Task Within , each higher priority task will execute at a most times The ceiling function gives the smallest integer greater than b the fractional number on which it acts E.g., the ceiling of 1/3 is 1, of 6/5 is 2, and of 6/3 is 2 Using the ceiling reflects the fact that will be preempted for c a full execution of a higher-priority released exactly at ’s end The total interference suffered by from in Time 20 30 40 50 60 70 80 where , is given by 010
2017/18 UniPD – T. Vardanega Real-Time Systems 179 of 515 2017/18 UniPD – T. Vardanega Real-Time Systems 181 of 515
Real Time Systems 4 2017/18 UniPD - T. Vardanega 10/03/2018
Response time equation Example: task set D
Task Period Computation Time Priority Utilization TC P U a 7 3 3 (high) 0.4285… b123 2 0.25 Where is the set of tasks with priority higher than c205 1 (low)0.25 Solved by forming a recurrence relationship
The set of values is monotonically non-decreasing When the solution to the equation has been found must not be greater than (e.g. 0 or )
2017/18 UniPD – T. Vardanega Real-Time Systems 182 of 515 2017/18 UniPD – T. Vardanega Real-Time Systems 184 of 515
Response time algorithm Example (cont’d)
for i in 1..N loop -- for each task in turn n := 0 If the recurrence does not converge loop before Ti we can still set a termination calculate new condition that attempts to determine
if then how long past Ti job i completes
exit value found end if if then exit value not found end if n := n + 1 end loop end loop
2017/18 UniPD – T. Vardanega Real-Time Systems 183 of 515 2017/18 UniPD – T. Vardanega Real-Time Systems 185 of 515
Real Time Systems 5 2017/18 UniPD - T. Vardanega 10/03/2018
Revisiting task set C Sporadic tasks
Task Period Computation Time Priority Response Time Sporadic tasks have a minimum inter-arrival time TC PR Which should be preserved at run time if schedulability is a80401 (low)80 to be ensured, but how can it ? b4010 2 15 They also require D c205 3 (high)5 The RTA for FPS works perfectly for D 2017/18 UniPD – T. Vardanega Real-Time Systems 186 of 515 2017/18 UniPD – T. Vardanega Real-Time Systems 188 of 515 Response time analysis /2 Hard and soft tasks RTA is a feasibility test In many situations the WCET given for sporadic Exact, hence necessary and sufficient tasks are considerably higher than the average case If the task set passes the test then all its tasks will Interrupts often arrive in bursts and an abnormal meet all their deadlines sensor reading may lead to significant additional If it fails the test then, at run time, some tasks will computation miss their deadline and FPS tells us exactly which Measuring feasibility with WCET may lead to very Unless the computation time estimations (the WCET) themselves turn out to be pessimistic low processor utilization being observed at run time We need some common sense to contain pessimism 2017/18 UniPD – T. Vardanega Real-Time Systems 187 of 515 2017/18 UniPD – T. Vardanega Real-Time Systems 189 of 515 Real Time Systems 6 2017/18 UniPD - T. Vardanega 10/03/2018 General common-sense guidelines Handing aperiodic tasks /2 Rule 1 : All tasks (hard and soft) should be schedulable using Besides preserving hard tasks and giving fair opportunities average execution times and average arrival rates for both to soft tasks, we still would like a solution that minimizes periodic and sporadic tasks The response time of the job at the head of the aperiodic queue There may therefore be situations in which it is not possible to meet all current deadlines Or the average response time of all aperiodic jobs for a given queuing discipline This condition is known as a transient overload Possible solutions Rule 2 : All hard real-time tasks should be schedulable using WCET and worst-case arrival rates of all tasks (including soft) Execute the aperiodic jobs in the background Execute the aperiodic jobs by interrupting the periodic jobs No hard real-time task will therefore miss its deadline Use slack stealing If Rule 2 incurs unacceptably low utilizations for non-worst- case jobs then WCET values or arrival rates must be reduced Use dedicated servers 2017/18 UniPD – T. Vardanega Real-Time Systems 190 of 515 2017/18 UniPD – T. Vardanega Real-Time Systems 192 of 515 Handing aperiodic tasks /1 Handing aperiodic tasks /3 They do not have minimum inter-arrival times Slack stealing And consequently no deadline Difficult to implement for preemptive systems We may be interested in the system being responsive to them For them, the slack is a not a constant, but it is a function of the We can run aperiodic tasks at a priority below the priorities time at which it is computed assigned to hard tasks The slack stealer is ready when the aperiodic queue is not In a preemptive system, they won’t steal resources from hard tasks empty; it is suspended otherwise But this does not provide adequate support to soft tasks which When ready and 0, the slack stealer is assigned the would often miss their deadlines highest priority; the lowest when 0 To improve the situation for soft tasks, a server can be employed Static computation of for some is useful but only when to bound the execution of aperiodic tasks the release jitter in the system is very low With servers, hard tasks will always have the processing Under EDF, 0 0 where 0 resources they need, and soft tasks will run as soon as possible ∑ ,.., for all jobs released in the hyperperiod starting at 0 2017/18 UniPD – T. Vardanega Real-Time Systems 191 of 515 2017/18 UniPD – T. Vardanega Real-Time Systems 193 of 515 Real Time Systems 7 2017/18 UniPD - T. Vardanega 10/03/2018 Computing the slack under EDF Computing the slack under FPS /2 The slack of periodic jobs of should be computed based on their effective deadline For a job of it should be computed at the beginning of the level- 1busy period that precedes so that 12 , , Hence the initial slack , 0 of every periodic job , 0 4 2 , 0 6 2 2.75 . , in the hyperperiod is determined as 0 2 8 2 2 2.75 . , 0 2 2 12 2 2 2 2.75 . , , 0, , ∑ , 0 3 2 12 3 2 2 2.75 . 2017/18 UniPD – T. Vardanega Real-Time Systems 194 of 515 2017/18 UniPD – T. Vardanega Real-Time Systems 196 of 515 Computing the slack under FPS /1 Slack stealing defeats optimality The amount of slack an FPS system has in a time Greed is no good: to minimize the response time of interval may depend on when the slack is used an aperiodic job, it may be necessary to schedule it To minimise the response time of an aperiodic job later, even if slack is currently available the decision on when to schedule it must For any periodic task set, under any FPS, and any aperiodic queuing policy, no valid algorithm exists that obviously consider the execution time of minimizes the response time of all aperiodic jobs No slack stealing algorithm under FPS can minimise the response time of every aperiodic job even with prior Similarly, no valid algorithm exists that minimizes the knowledge of their arrival and execution times average response time of the aperiodic jobs Better not be greedy in using the available slack 2017/18 UniPD – T. Vardanega Real-Time Systems 195 of 515 2017/18 UniPD – T. Vardanega Real-Time Systems 197 of 515 Real Time Systems 8 2017/18 UniPD - T. Vardanega 10/03/2018 Handing aperiodic tasks /4 Handing aperiodic tasks /6 period Periodic server (PS) – general model Deferrable Server (DS), a bandwidth-preserving PS A notional ( , ) periodic task scheduled at the DS retains its budget if no aperiodic tasks require execution highest priority to only execute aperiodic jobs If an aperiodic job requires execution during the DS period, it can be The PS has a budget of time units and a replenishment served immediately: when idle, the DS stays ready (not idle) of length The budget is replenished at the start of the new period (!) When the PS is scheduled and executes aperiodic jobs, it If an aperiodic job arrives time units before the end of , the consumes its budget at the rate of 1 unit per unit of time request begins to be served and blocks periodic tasks Budget is exhausted when 0and replenished periodically When the budget is replenished, new aperiodic jobs may then be The PS is backlogged when the aperiodic job queue is served for the full budget nonempty and it is idle otherwise If that happens, in , DS contributes a solid interference Eligible for execution only when ready, backlogged and 0 of , longer than 1 per busy period 2017/18 UniPD – T. Vardanega Real-Time Systems 198 of 515 2017/18 UniPD – T. Vardanega Real-Time Systems 200 of 515 Handing aperiodic tasks /5 Handing aperiodic tasks /7 Polling server, a simple (naïve) kind of PS Priority Exchange (PE), similar in principle to DS It is given a fixed budget that it uses to serve aperiodic If PE is idle when scheduled, it exchanges its own task requests that is replenished at every period priority with that of the pending periodic task with The budget is immediately consumed if the server is priority lower than itself and higher of all other pending scheduled while idle periodic tasks Ready periodic tasks – if any – execute instead The selected periodic task inherits PE’s higher priority It is not bandwidth preserving An aperiodic job that arrives just after the server has been until an aperiodic task arrives or PE’s ready period ends scheduled while idle, must wait until the next replenishment time Bandwidth-preserving servers need additional rules for consumption and replenishment of their budget 2017/18 UniPD – T. Vardanega Real-Time Systems 199 of 515 2017/18 UniPD – T. Vardanega Real-Time Systems 201 of 515 Real Time Systems 9 2017/18 UniPD - T. Vardanega 10/03/2018 Handing aperiodic tasks /8 SS rules unveiled Sporadic Server (SS), fixes the bug in DS Let be the time at which SS has full budget and becomes backlogged, and the time at which SS becomes idle The budget is replenished only when exhausted and at a minimum guaranteed distance from its earlier execution In the , interval, when SS is continuously active, three Hence no longer at a fixed rate cases are possible 1. SS has consumed no capacity: No replenishment, and This places a tighter bound on its interference and makes no interference in that interval schedulability analysis simpler and less pessimistic 2. SS has consumed all capacity: Full replenishment, and This is the default server policy in POSIX bounded interference in that interval 3. SS has consumed fractional capacity: Fractional replenishment, and interference lower than allowed in that interval 2017/18 UniPD – T. Vardanega Real-Time Systems 202 of 515 2017/18 UniPD – T. Vardanega Real-Time Systems 204 of 515 SS rules under FPS Handing aperiodic tasks /9 Consumption rules SS is more complex than PS or DS At time (the latest replenishment time), a backlogged SS consumes Its rules require keeping tab of lots of data budget only if executing, hence when no higher-priority task is ready Several cases to consider when making scheduling decisions The replenishment is limited to the quantity of actual consumption This complexity is acceptable because the schedulability of a SS is Replenishment rules easy to demonstrate Under FPS, SS equates to a periodic task with , records the time that SS’ budget was last replenished records the time when SS first begins to execute since EDF and LLF use a dynamic variant of SS as well as other is the latest time at which a lower-priority task than SS executes bandwidth-preserving server algorithms known as The next replenishment time is set to Constant utilization server Exception Total bandwidth server If only higher-priority tasks had been busy since , then Weighted fair queuing server and SS is late: hence, budget fully replenished as soon as exhausted 2017/18 UniPD – T. Vardanega Real-Time Systems 203 of 515 2017/18 UniPD – T. Vardanega Real-Time Systems 205 of 515 Real Time Systems 10 2017/18 UniPD - T. Vardanega 10/03/2018 Task sets with D < T DMPO is optimal /2 For , Rate Monotonic priority assignment Let , be two tasks with adjacent priorities in such that under we have ∧ (a.k.a. ordering) is optimal Define scheme to be identical to except that tasks , For , Deadline Monotonic priority ordering are swapped is optimal Now consider the schedulability of under All tasks with priority will be unaffected All tasks with priority will be unaffected as they will experience the same interference from and Task which was schedulable under , now has a higher priority, suffers less interference, and hence must be schedulable under 2017/18 UniPD – T. Vardanega Real-Time Systems 206 of 515 2017/18 UniPD – T. Vardanega Real-Time Systems 208 of 515 DMPO is optimal /1 DMPO is optimal /3 Deadline monotonic priority ordering (DMPO) is optimal All that is left to show is that task , which has had its priority lowered, is still schedulable any task set that is schedulable by priority-driven scheme Under we have , and it is also schedulable by DMPO Task only interferes once during the execution of task hence The proof of optimality of DMPO involves transforming Under task completes at the time task did under the priorities of as assigned by until the ordering Hence task is still schedulable after the switch becomes as assigned by DMPO Priority scheme can now be transformed to by choosing Each step of the transformation will preserve schedulability two more tasks that are in the wrong order for DMPO and switching them 2017/18 UniPD – T. Vardanega Real-Time Systems 207 of 515 2017/18 UniPD – T. Vardanega Real-Time Systems 209 of 515 Real Time Systems 11 2017/18 UniPD - T. Vardanega 10/03/2018 Summary A simple (periodic) workload model Delving into fixed-priority scheduling A (rapid) survey of schedulability tests Some extensions to the workload model Priority assignment techniques 2017/18 UniPD – T. Vardanega Real-Time Systems 210 of 515 Selected readings N.C. Audsley, A. Burns, R.I. Davis, K.W. Tindell, A.J. Wellings (1995) Fixed priority pre-emptive scheduling: an historical perspective DOI: 10.1007/BF01094342 D. Faggioli, M. Bertogna, F. Checconi (2010) Sporadic Server revisited DOI: 10.1145/1774088.1774160 2017/18 UniPD – T. Vardanega Real-Time Systems 211 of 515 Real Time Systems 12