1 / 75

Contract-based scheduling

Contract-based scheduling. Giuseppe Lipari. Summary. Overview of classical scheduling theory Limitations of classical scheduling Contract based scheduling Techniques: Resource Reservations and periodic servers Bandwidth Inheritance Applications Hard and soft real-time tasks

arnon
Télécharger la présentation

Contract-based scheduling

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Contract-based scheduling Giuseppe Lipari

  2. Summary • Overview of classical scheduling theory • Limitations of classical scheduling • Contract based scheduling • Techniques: • Resource Reservations and periodic servers • Bandwidth Inheritance • Applications • Hard and soft real-time tasks • Supporting imprecise computation model with contracts • Hierarchical scheduling • Component based systems • Adaptive Systems • Feedback control MOTIVES - ARTIST 2 Winter School

  3. Classical Scheduling Theory MOTIVES - ARTIST 2 Winter School

  4. Classical Scheduling Theory • In this presentation we address scheduling in mono-processor systems • The methodologies we describe are more general, and can be applied to other resources • Scheduling algorithm • An on-line algorithm that selects which task is to be executed at each instant of time • Problem • given a set of real-time tasks and a scheduling algorithm, check a-priori if all timing constrains will be respected MOTIVES - ARTIST 2 Winter School

  5. Classical Task Model • Real-Time system = set of concurrent real-time tasks • Task: sequence of jobs (or instances) • Periodic or sporadic task • T is the period (or minimum inter-arrival time) MOTIVES - ARTIST 2 Winter School

  6. Scheduling analysis OFF- LINE Design model Task model (timing) Scheduling Analysis Schedule Properties Implementation Scheduler Schedule RUN-TIME MOTIVES - ARTIST 2 Winter School

  7. Scheduling Algorithms • Table driven • Schedule is entirely computed off-line and stored in a table • Maximum degree of predictability, but too rigid • E.g. Time Triggered Architecture • Fixed Priority • Each task is assigned a priority • Predictable but also flexible • The most popular (all RTOS implement FP) • Earliest Deadline First • Each job has a priority inversely proportional to its deadline • Flexible and optimal • But not implemented in practice MOTIVES - ARTIST 2 Winter School

  8. Hard real-time systems • Safety critical hard real-time applications • Severe consequences if some timing constraint is violated • Most important objective is to meet all timing constraints • Cost is a secondary issue • Fault-tolerance is a major issue • Design for Worst-Case • Overestimation of resources • Examples: • Avionic and space systems • Nuclear plants • Etc. MOTIVES - ARTIST 2 Winter School

  9. Modern real-time applications • A new class of real-time applications • Cost is an important factor • Overestimation of resources can unnecessarily increase the cost • Strong push toward “adaptive” and “robust” techniques • E.g. automotive • Soft real-time systems • Cost is a major factor • Optimization of resources is very important • Some timing constraint can be missed • Emphasis on Quality of Service control • Design for average case • E.g. Consumer Electronics, Multimedia systems, etc. MOTIVES - ARTIST 2 Winter School

  10. Limitations of classical scheduling • An accurate timing analysis requires • An accurate model of the Hardware platform • An accurate model of the software (inputs/outputs/frequencies of events) • Long and expensive • WCET can be much higher than average • Design for worst-case  waste of resources  increases the cost Design model Task model (timing) Scheduling Analysis Schedule Properties Implementation Scheduler Schedule MOTIVES - ARTIST 2 Winter School

  11. Limitations of FP and EDF • There is no “temporal protection” • Suppose that we underestimate the WCET of a task • The analysis will not report any problem • At run-time one or more tasks can miss their deadlines • Not all code is always under our control • In large projects, it is common to include code from third-parties • A non critical task written by someone else could compromise the schedulability analysis MOTIVES - ARTIST 2 Winter School

  12. task1 task2 Temporal fault task1 task2 Executing more than expected... task2 fails!! MOTIVES - ARTIST 2 Winter School

  13. Example with EDF • Three tasks scheduled by EDF • C1=1, T1=4 • C2=?, T2=6 • C3=2, T3=8 task1 task2 task3 It’s executing too much... (5 instead of 3) Deadline miss! MOTIVES - ARTIST 2 Winter School

  14. Design for average case • Consider a soft real-time application • Worst case >> Average case • Allow deadline miss but … • … keep them under control! • If we use classical scheduling algorithms (FP or EDF) • Design for worst-case  waste of resources • Design for average-case  difficult to give guarantees • Probabilistic schedulability analysis • The model is too complex (requires probabilistic characterization of all tasks) • The behavior of one task depends on the behavior of every other task • No easy “knob” to control QoS of tasks MOTIVES - ARTIST 2 Winter School

  15. Limitations of Fixed Priority • Fixed Priority Scheduling • Each task is assigned a priority • The highest priority active task executes • Rate Monotonic assignment is optimal for schedulability and resource utilization • How to assign priorities? • What is the relation between priority and “importance / criticality”? • More important / critical task should have higher priority • The most important tasks are not necessarily the ones with the shorter periods • Lower priority tasks could be delayed by higher priority ones MOTIVES - ARTIST 2 Winter School

  16. Fixed priority and Components • Example: • Consider two components developed independently. Each one consists of two tasks, for a total of 4 tasks. The scheduler is FP (Fixed Priority). • Problem: • Priorities are relative • The designer of one component can only assing local priorities • It is not clear how to transform local priorities into global priorities at integration phase • No temporal isolation • A failing task of one component can delay the execution of other components MOTIVES - ARTIST 2 Winter School

  17. Component C1 Component C2 Task1 Task2 Task3 Task4 Task1 Task2 Task3 Task4 Global scheduler Problems with a single scheduler prio(Task1) > prio(Task2) prio(Task3) > prio(Task4) Possible priority ordering: 1. prio(Task1) > prio(Task2) > prio(Task3) > prio(Task4) 2. prio(Task1) > prio(Task3) > prio(Task2) > prio(Task4) 3. prio(Task3) > prio(Task1) > prio(Task2) > prio(Task4) 4. prio(Task3) > prio(Task4) > prio(Task1) > prio(Task2) 5. prio(Task1) > prio(Task3) > prio(Task4) > prio(Task2) 6. prio(Task3) > prio(Task1) > prio(Task4) > prio(Task2)

  18. Schedulability Analysis • Scheduling analysis can only be performed when • We already have all tasks with their code • We have performed WCET analysis • It is the final step! • Most of the times it comes too late • If the system is not schedulable, it is not easy to understand how to change the system • Scheduling analysis is not composable • Cannot be done separately on smaller subsystems • Requires too much effort and time • Only useful for safety critical systems MOTIVES - ARTIST 2 Winter School

  19. Summary: why RT analysis? • What we ask real-time & embedded system developers • develop correct concurrent and distributed software • measure WCETs • make a real-time analysis • short time-to-market & cheap • What do we give them • low level OS primitives • no integrated methodology for measuring WCETs • analysis tools not integrated in the process • Real-time theory regarded as “solution to the wrong problem” MOTIVES - ARTIST 2 Winter School

  20. What we propose • High-level real-time services • with built-in analysis • platform-independent • high-level quality of service management • Temporal encapsulation of subsystems • Support the composability of independently developed components • full view of resource protection (processors, networks, busses, memory, power, ...) • Designed for component-based design methodologies • as an enabling technology MOTIVES - ARTIST 2 Winter School

  21. Contract Based Scheduling MOTIVES - ARTIST 2 Winter School

  22. Objectives • A scheduling algorithm • Temporal protection • On-line admission control • Appropriate OS primitives • Platform-independent • “standard” • That allow QoS management and control • A scheduling analysis • Composable MOTIVES - ARTIST 2 Winter School

  23. FIRST and FRESCOR projects • The FIRST project • 5th framework EU project, concluded in 2004 • A platform independent API for contract-based scheduling • Implemented in two OS: MARTE and Shark • Implementation and documentation available at http://shark.sssup.it • The FRESCOR project • 6th framework EU project, started July 2006 • Extend API to multiple resources, multiprocessors, Quality of service management • Implementation will be performed on Linux and RT-Linux MOTIVES - ARTIST 2 Winter School

  24. Contracts • The contract model • The application specifies its resource requirements in a “contract” • The system performs an admission control test • If the contract is accepted, the application is admitted and reserved a certain amount of resources • The contract can only be broken by the application itself • Application • A single task • A set of tasks plus a local scheduler (for hierarchical scheduling) MOTIVES - ARTIST 2 Winter School

  25. Real-Time Contracts MOTIVES - ARTIST 2 Winter School

  26. The contract model in FIRST • Set of modules, each one contains the API for a specific and well defined subset of functionalities Core Implementation specific First Scheduling Framework Shared objects Hierarchical schedulers Dynamic reclamation Spare capacity sharing Distribution MOTIVES - ARTIST 2 Winter School

  27. P Q D Contract parameters • Core parameters • (Qmin, Qmax) min and max budget • (Pmin, Pmax) min and max budget • Deadline • Granularity = (discrete | continuous) • Signaling • Negotiation • If it can be admitted, selects (Q, P) • At run-time, it guarantees Q every P units of time, within D from the start MOTIVES - ARTIST 2 Winter School

  28. Resource Reservations • The underlying scheduling mechanism is based on Resource Reservations • Each application is reserved a fraction of the resource in terms of (budget, period) • The application is guaranteed to receive at least that amount of resource • Resource Reservation algorithms • There are many, for FP and for EDF • FP: Polling server, Sporadic Server, Deferrable Server • EDF: Constant Bandwidth Server (CBS), GRUB, CASH, … MOTIVES - ARTIST 2 Winter School

  29. Resource partition Resource enforcement 10 % 20 % t4 • A mechanism that prevents a task to consume more than its reserved amount. • If a task executes more, it is delayed, preserving the resource for the other tasks. t1 t3 t2 25 % 45 % Each application receives a bandwidth Ui = Qi / Pi Resource Reservations MOTIVES - ARTIST 2 Winter School

  30. Scheduling • Each reservation is managed by a “server” • SERVER = An object internal to the OS that updates run-time state of the reservation • Each Reservation can handle more than one task (hierarchical scheduling) U1 t1 server Ready queue U2 t2 CPU server t3 EDF U3 server U1 + U2 + U3 1 t4 MOTIVES - ARTIST 2 Winter School

  31. Virtual Processor Analogy • A task in a reservation behaves approximately like on a dedicated virtual processor • The approximation is given by the time granularity of the allocation (the period of the reservation P) 1 P1 1 2 3 Prioritized Access READY QUEUE 2 P2 3 P3 1 1 U1 50% Resource Reservation 2 U2 2 30% U3 3 20% 3 MOTIVES - ARTIST 2 Winter School

  32. Example with reservations • Three processes, with reservations • Q1=1, P1=4, U = 0.25 • Q2=3, P2=6, U = 0.5 • Q3=2, P3=8, U = 0.25 Needs to execute 5 instead of 3... Needs to execute 2… MOTIVES - ARTIST 2 Winter School

  33. Properties • Individual timing guarantees • The ability of a task to meet its deadline depends only on the amount of resources reserved to it • If a task wants to use more than reserved, it is delayed and does not influence the rest of the tasks • Approximation of Virtual Processor • Independence from underlying scheduling algorithm • The designer needs not to know about FP or EDF, but only about the reservation • Toward a component-based methodology • It is possible to analyze a subsystem independently of the others! MOTIVES - ARTIST 2 Winter School

  34. Design Process OFF- LINE Design model Subsystem Task model (timing) Scheduling Analysis Sub-Schedule Properties Subsystem Task model (timing) Scheduling Analysis Sub-Schedule Properties Contract Implementation Scheduler Schedule Contract Implementation RUN-TIME MOTIVES - ARTIST 2 Winter School

  35. Guarantees and reclamation • Negotiation • Schedulability test depends on underlying scheduling algorithm • FP: response time analysis for “servers” • EDF: utilization-based test or pseudo-polynomial test • Admission based on Qmin and Tmax • Spare Capacity • If there is free space, the algorithm computes Qmin < Q < Qmax and Pmin < P < Pmax • Distribution of free space based on weights • Dynamic reclamation • At run-time, use the extra capacity not used by other tasks • If (Q, P) has been negotiated, at run time the task can get more than Q MOTIVES - ARTIST 2 Winter School

  36. D R G Qmin Tmax Contract Negotiation • Client/server structure: • the service thread is assigned a contract • response time: • Service thread contract params: (Cmin, Tmax, D) • Computation time for negotiation: G User Thread Service Thread msg queue fsf_negotiate_contract() msg queue MOTIVES - ARTIST 2 Winter School

  37. Scheduling techniques MOTIVES - ARTIST 2 Winter School

  38. Resource Reservation Scheduling • Many scheduling algorithms • Aperiodic servers (Polling, Deferrable, Sporadic, Constant Bandwidth Servers) • Many reclamation algorithms (CASH, BASH, IRIS, …) • We present GRUB • (Greedy Reclamation of Unused Bandwidth) • A RR scheduling algorithm based on EDF • Based on CBS • Properties • Virtual processor analogy • Dynamic reclamation of bandwidth • Can be used for hierarchical system MOTIVES - ARTIST 2 Winter School

  39. GRUB • System = set of “servers” • A server is the run-time object that manages a reservation • Server • Parameters: (Q, P), U = Q / P • Variables: d = server deadline, V = virtual time • States and transitions: MOTIVES - ARTIST 2 Winter School

  40. Rules • Initially, server is inactive • When task is activated (1.a) • V=t, d=t+P • While task execute • dV = dt U / Uact • If V = d (and task not completed) (4) • Go to depleted until d = t • When budget recharged (5) • V = t, d = d + P • When task completes • until V < t, stay in completed (2.b) • When V ≥ t, go to inactive (2.c or 3) • Active servers • Servers not in inactive MOTIVES - ARTIST 2 Winter School

  41. d An example of execution U = 0.5 P= 5 V Cont. Depl. Inac Comp. t MOTIVES - ARTIST 2 Winter School

  42. 0 0 2 2 4 4 6 6 8 8 10 10 12 12 14 14 16 16 An example of execution (VP analogy) • Two tasks • Task 1 requires C=[2,4], T=8; it is assigned Q=4, P=8, U=0.5 • Task 2 requires C=[4,8], T=12; it is assigned Q=6, P=12, U=0.5 (2) (4) Task1 0 2 4 6 8 10 12 14 16 t inactive VP1 V1 (8) Task2 t VP2 V2 Uact t

  43. Shared Resources • Resource Reservations are for independent tasks • Interaction model • Shared memory • Critical sections guarded by mutex semaphores • Blocking time due to locked critical sections • Tasks cannot be considered “independent” anymore • Bandwidth Inheritance Protocol (BWI) • Extends Priority Inheritance to Resource Reservations • Temporal isolation between non-interacting servers is maintained • Limited interference between interacting servers MOTIVES - ARTIST 2 Winter School

  44. Bandwidth Inheritance • Priority Inheritance • A task inside a critical section inherits the priority of the blocked tasks • Bandwidth Inheritance • A task inside a critical section inherits the bandwidth (i.e. the pair Q, P) of the blocked tasks • Interference: a task can steal the reservation of someone else only for the duration of one critical section • It is possible to compute maximum interference (under certain conditions) • Temporal isolation is broken but: • Interference limited to interaction tasks and limited to critical sections • Non interacting tasks are temporally isolated MOTIVES - ARTIST 2 Winter School

  45. Applications MOTIVES - ARTIST 2 Winter School

  46. Hard real-time tasks • Contract Parameters • Qmin=Qmax= WCET of the thread • Pmin=Pmax= thread’s period • D = thread’s deadline • budget overrun exception handling • Advantages • The thread is protected from the other non-RT and soft RT threads in the system (temporal isolation) • if dynamic reclaimation, the spare capacity of this thread can be given to others MOTIVES - ARTIST 2 Winter School

  47. Soft real-time tasks • Contract Parameters • Qmin – Qmax = variation of the execution time • Pmin=Pmax= thread’s period • D = thread’s deadline • Advantages • Does not impact on other threads (temporal isolation) • minimum service is guaranteed • Takes advantage of capacity sharing and dynamic reclamation (to minimize deadline misses) • can re-negotiate if it needs more MOTIVES - ARTIST 2 Winter School

  48. Imprecise computation model • Thread consists of a mandatory part and N optional parts • WCET of mandatory part = M • WCET of i-th optional part = Oi • What is needed • Core + (capacity sharing) + (dynamic recl.) + (shared res. synch.) • Contract Parameters • Cmin = M • Cmax = M + O1 + ... + ON • Tmin = Tmax = thread’s period • D = thread’s deadline MOTIVES - ARTIST 2 Winter School

  49. Get remaining capacity If enough capacity execute optional part Example: thread structure for imprecise computation void task_body(void *arg) { ... pthread_t my_pid = (pthread_t)(arg); int i; sys_gettime(&acttime); fsf_get_server(&server, my_pid); while(1) { /* Mandatory Body */ for (i=0; i<N; i++) { fsf_get_available_capacity(server, &capacity); if (capacity > O[i]) { /* Optional Code */ } else break; } ADDUSEC2TIMESPEC(uperiod,&acttime); fsf_schedule_next_timed_job(&acttime,&budget,&period, &budget_missed,&deadline_missed); } } MOTIVES - ARTIST 2 Winter School

  50. Evaluation of dynamic reclamation • First experiment • 4 periodic tasks • with variable execution time [1,15] msec, 100 msec period • Each one is assigned a budget of 15 msec over a period of 100 msec (15%) • 2 non-periodic tasks trying to reclaim as much as they can • they are assigned two servers • budget Qmin,max = 3 msec, period Pmin,max = 60 msec (5% each) • Results MOTIVES - ARTIST 2 Winter School

More Related