Zeitgesteuerte Scheduling-Strategien in Echtzeitsystemen

Transkript

1 Wanja Hofer Hauptseminar Ausgewählte Kapitel eingebetteter Systeme Lehrstuhl 4 Betriebsysteme und Verteilte Systeme Zeitgesteuerte Scheduling-Strategien in Echtzeitsystemen Inhaltsverzeichnis 1 Einführung Echtzeitsysteme und Scheduling Zeitgesteuertes Scheduling Erstellung eines einfachen zeitgesteuerten Ablaufplans Verbesserung des Cyclic Schedule Frame Size Constraints Scheduler Cyclic Executive Scheduling von aperiodischen Jobs (Verbesserung der Antwortzeit) 5 4 Scheduling von sporadischen Jobs per Cyclic EDF -Algorithmus 6 5 Praktische Aspekte Behandlung von Frame Overruns Ausführung von Modus-Wechseln Aperiodischer Modus-Wechsel (weiche Deadline) Sporadischer Modus-Wechsel (harte Deadline) Beurteilung des Ansatzes Vorteile Nachteile Literaturquellen 9 1

2 1 Einführung 1.1 Echtzeitsysteme und Scheduling Kopetz: A real-time computer system is a computer system in which the correctness of the system behavior depends not only on the logical results of the computations, but also on the physical instant at which these results are produced. Echtzeitsysteme beinhalten periodische Tasks mit harten Deadlines, die regelmässig zur Ausführung bereit stehen, aperiodische Tasks mit weichen Deadlines, die zu vorher unbekannten Zeitpunkten auftreten, und sporadischen Tasks (aperiodische Tasks mit harter Deadline), die es zu schedulen gilt. Alle Tasks besitzen die Parameter release time, execution time und relative deadline, die periodischen zusätzlich die Periode. Echtzeit-Scheduling-Strategien lassen sich kategorisieren in clock- / time-driven strategies (zeitgesteuertes Scheduling, wird hier besprochen) weighted round-robin strategies (vor allem für Echtzeit-Netzwerke) event- / priority-driven strategies (siehe Vortrag von Sven Kerschbaum) 1.2 Zeitgesteuertes Scheduling Zeitgesteuerte Scheduling-Strategien eignen sich hauptsächlich für weitestgehend deterministische Systeme Scheduling-Entscheidungen werden nicht bei bestimmten Ereignissen (z. B. Job-Release oder Job-Completion), sondern an vorher definierten Zeitpunkten getroffen. Diese Zeitpunkte werden offline im Voraus berechnet und in einer Scheduling-Tabelle gespeichert, da die Parameter der periodischen Tasks a priori bekannt sind. Die Tabelle enthält im einfachsten Fall nur Einträge der Form (Entscheidungszeit, geschedulter Job). Der eigentliche Scheduler führt zur Laufzeit die Jobs entsprechend der Tabelle aus und muss sich ggf. noch um die Unterbringung von aperiodischen und sporadischen Tasks kümmern. Dabei muss er den Timer nach jeder Entscheidung neu setzen, sodass ein Timer-Interrupt zur nächsten Entscheidungszeit eintrifft. minimierter Overhead zur Laufzeit, komplexe Algorithmen verwendbar Voraussetzungen / Annahmen: Parameter von Tasks mit harten Deadlines (periodische und sporadische Tasks) bekannt Hardware-Timer mit möglichst hoher Granularität vorhanden Zeit, bis Scheduler nach timer-interrupt ausführt, nach oben hin begrenzt und kalkulierbar 2

3 2 Erstellung eines einfachen zeitgesteuerten Ablaufplans Notation periodischer Tasks: 4-Tupel (Phase, Periode, Ausführungszeit, Deadline), standardmäßig Phase=0, Deadline=Periode Beispiel: T 1 = (4, 1), T 2 = (5, 2), T 3 = (20, 1), T 4 = (20, 2); interessante Größe: Utilization (prozentual benötigte Ausführungszeit), hier = 25% + 40% + 5% + 10% = 80% Scheduling evtl. möglich Zufällig generierter Ablaufplan für eine Hyperperiode: So ein periodischer und statischer Ablaufplan wird Cyclic Schedule genannt. Wofür nutzt man Lücken? Scheduling von aperiodischen (und sporadischen) Tasks und schließlich auch Nicht-Echtzeit-Tasks Da es mehrere verschiedene geeignete Scheduling-Pläne, um alle Tasks unterzubringen, müssen bestimmte Kriterien gewählt werden, um einen objektiv guten Plan auszuwählen: Ziel: gleichmäßige Lückenverteilung für gleichmäßige Antwortzeit aperiodischer Tasks 2.1 Verbesserung des Cyclic Schedule Idee: regelmäßige Frames für regelmäßige Scheduling-Entscheidungen Vorteile: keine Preemption innerhalb eines Frames Überwachungsfunktionen am Anfang eines Frames: - Erkennung von Overruns frühzeitige Reaktion / Weiterleitung an die Anwendung möglich - Überprüfung, ob alle Jobs des aktuellen Frames zur Ausführung bereit stehen regelmäßiger Timer-Interrupt, Timer-Ablaufzeit muss nicht neu gesetzt werden 2.2 Frame Size Constraints Wie groß sollte die Frame-Size gewählt werden? Überlegungen: 3

4 1. Frames sollten nach Möglichkeit mindestens so lang sein, dass kein Job unterbrochen werden muss: f max(e i ) 2. Damit Schedulingplan möglichst klein wird, sollte f die Hyperperiode teilen Plan nur für eine Hyperperiode nötig, wenig Speicher nötig 3. Frames müssen klein genug sein, damit zwischen der Release-Time und der Deadline jedes Jobs mindestens ein Frame liegt nur so kann der Scheduler feststellen, ob ein Job seine Deadline einhält 2f ggt (p i, f) D i für jeden periodischen Task i Am Beispiel: 1. f 2 2. f 20 f = 2/4/5/10/20 3. nach Überprüfung des 3. Constraint für alle 4 Tasks ergibt sich nur f = 2 Beispiel-Ablaufplan mit Frame-Size f = 2: Diese 3 Frame Size Constraints konkurrieren teilweise und sind nicht immer alle gleichzeitig erfüllbar, obwohl ein Scheduling möglich ist. Deshalb ist man u. U. gezwungen, den ersten Constraint zu verletzen und einen Job in mehrere Job Slices zu partitionieren. Dadurch steigt aber natürlich auch der Overhead für Context Switches und die Kommunikation zwischen den Slices. Zusammenfassung: Erstellung Schedulingplan für periodische Tasks 1. Frame Size f festlegen 2. Jobs in Job Slices partitionieren, falls nötig 3. Job Slices in Frames positionieren 4

5 2.3 Scheduler Cyclic Executive Ein Cyclic Executive ist ein Scheduler basierend auf auf einer Tabelle und einem regelmäßigen Ablaufplan: Clock Interrupts zu Beginn jedes Frames Überprüfung auf Frame Overruns des alten Frames spezifischen Handler aufrufen Ablaufplan des aktuellen Frames wird in den Speicher geholt periodische Jobs werden hintereinander ausgeführt aperiodische Jobs ausführen, falls Aperiodic Job Queue nicht leer und noch Zeit im Frame vorhanden falls immer noch Zeit: idle bis zum nächsten Clock Interrupt 3 Scheduling von aperiodischen Jobs (Verbesserung der Antwortzeit) Bei den bisherigen Ansätzen wurden aperiodische Jobs im Hintergrund der periodischen Jobs ausgeführt. Überlegung: frühzeitige Beendigung von Jobs mit harter Deadline bringt keinen Vorteil, ABER: aperiodische Jobs werden als Reaktion auf (System-)Ereignis ausgelöst je früher Scheduling von aperiodischen Jobs, desto reaktionsfreudiger das System Ansatz: zuerst Ausführung aperiodischer Jobs soweit wie möglich, danach Scheduling periodischer Jobs (sog. Slack Stealing) Slack Time y = f x k : Zeit, die in Frame k nicht von periodischen Jobs belegt ist Slack Stealing, solange aperiodische Jobs in der Queue sind und Slack vorhanden ist Nach jedem periodischen Job Slice wird Aperiodic Job Queue überprüft und ggf. ein aperiodischer Job ausgeführt, falls Slack vorhanden ist. Am Beispiel: Neben den beiden periodischen Tasks T 1 und T 2 tritt zum Zeitpunkt t = 4 ein aperiodischer Task A 3 mit Ausführungszeit 1.5 auf. Ohne Slack Stealing beträgt die Antwortzeit 5.5: Mit Slack Stealing beträgt die Antwortzeit 4.5: 5

6 Implementierung des Slack Stealing: Setzen eines Interval Timers auf die noch verfügbare Slack Time, sobald aperiodische Jobs ausgeführt werden periodische Jobs erfüllen immer ihre Deadline Probleme: Granularität des Interval Timers meist nur im ms-bereich Parameter der periodischen Jobs müssen größer sein Overruns von periodischen Jobs haben keinen Puffer 4 Scheduling von sporadischen Jobs per Cyclic EDF -Algorithmus Sporadische Jobs besitzen wie periodische Jobs harte Deadlines, im Gegensatz zu ihnen sind jedoch Auslösezeitpunkte und Ausführungszeiten im Voraus unbekannt. Garantie für sporadische Jobs a priori unmöglich Lösung: Acceptance Test Überprüfung, ob Scheduling neben periodischen Jobs und schon angenommenen anderen sporadischen Jobs möglich Ausführungszeit muss zum Auslösezeitpunkt bekannt werden, Job muss unterbrechbar sein Ggf. sofortige Zurückweisung des Jobs genügend Zeit für eine entsprechende Reaktion der Anwendung Bei gleichzeitiger Überprüfung mehrerer Jobs Testreihenfolge nach EDF (Earliest Deadline First) Algorithmus Cyclic EDF für sporadischen Job S(d, e) mit Deadline d und Ausführungszeit e, Acceptance Test zu Beginn von Frame t Annahme: d liegt in Frame l + 1 Scheduling von S in Frames t, t + 1,..., l 1. Wenn gesamte Slack Time im Intervall [t,..., l] kleiner als e Ablehnung von S Sonst weitere Überprüfung in Schritt 2 2. Wenn durch Annahme von S andere schon angenommene sporadische Jobs ihre Deadline verpassen würden Ablehnung von S Ansonsten Akzeptieren und Einfügen von S in Schedulingplan 6

7 Analyse des Cyclic EDF -Algorithmus: optimal im folgenden Sinne: wenn Scheduling einer Menge von sporadischen Jobs möglich, dann findet der Algorithmus immer einen Schedulingplan Nachteil: Acceptance Tests nur zu Beginn von Frames Interrupt-driven Scheduler besser (Überprüfen zum Auslösepunkt eines Jobs) Vorteil: periodische Jobs werden nicht gefährdet Anzahl an Context Switches und Acceptance Tests sonst unvorhersehbar nicht optimal im folgenden Sinne: optimale Entscheidungen ohne Wissen über zukünftige sporadische Jobs nicht möglich; Scheduling von kleinen Jobs verhindert u. U. Annehmen von kurz danach auftretenden großen Jobs 5 Praktische Aspekte 5.1 Behandlung von Frame Overruns Frame Overruns können auftreten durch a) eine ungewöhnliche Kombination von Input, b) einen spontanen Hardware-Fehler oder c) einen vorher unbemerkten Bug in der Software. Die angemessene Behandlung ist abhängig von der Anwendung: 1. Abbrechen des betroffenen Jobs und Logging des Ereignisses für spätere Recovery in Systemen, bei denen verspätete Ergebnisse unbrauchbar sind 2. Baldmöglichste Unterbrechung und Scheduling des restlichen Jobs als aperiodischer Job inkonsistente Zustände werden vermieden 3. Weitere Ausführung des betroffenen Jobs kann weitere Jobs dazu bringen, ihre Deadline zu verpassen (Kettenreaktion) 5.2 Ausführung von Modus-Wechseln Bis jetzt nur Betrachtung eines Modus mit bestimmten periodischen Tasks bei Hinzufügen und Entfernen von periodischen Tasks wird Modus-Wechsel nötig Neuer Schedulingplan kann vorberechnet werden Plan und Code der neuen Tasks müssen nur in den Speicher geholt werden Wechsel mit weicher oder harter Deadline je nach Anwendungs- / Benutzeranforderung möglich 7

8 5.2.1 Aperiodischer Modus-Wechsel (weiche Deadline) Scheduling des Mode-Change Jobs als normaler aperiodischer Job mit höchster Priorität, während der Ausführung Modifikation des Ausführungsplans zur Beschleuigung des Modus-Wechsels: Keine Acceptance Tests für neue sporadische Tasks Markieren der zu löschenden periodischen Tasks Ausführen des Mode-Change Jobs während der Zeit, zu der markierte Jobs laufen sollten weiterausführende periodische Tasks bleiben unverändert während des Modus-Wechsels Umschalten zu neuer Scheduling-Tabelle, sobald diese und der Code der neuen Tasks im Speicher Abwägung: Sporadische Jobs sollten nicht betroffen sein, da ihre zeitgerechte Ausführung garantiert worden ist vs. Antwortzeit auf die Mode-Change-Anfrage sollte nicht zu lang werden evtl. Inkaufnahme von zu spät terminierenden sporadischen Jobs Entscheidung nur nötig, wenn sporadische Jobs nach neuem Plan nicht zeitgerecht terminieren würden Sporadischer Modus-Wechsel (harte Deadline) Scheduling des Mode-Change Jobs als normaler sporadischer Job, allerdings nur, wenn die aufrufende Aufwendung eine Zurückweisung des Jobs akzeptieren kann (indem sie ihn z. B. zurückstellt oder eine alternative Aktion ausführt). Wenn eine Zurückweisung nicht akzeptabel ist, folgende Alternative: Scheduling des Mode-Change Jobs als periodischer Job mit entsprechend kleiner Periode (abhängig von der Antwortzeit) Pro: Zeitgerechte Ausführung eines sporadischen Modus-Wechsels garantiert Contra: Unter Umständen extreme Reduktion der Prozessorbandbreite für periodische Tasks Kompromiss: Solange alle gewünschten periodischen Tasks einplanbar sind, kann ungenutzte Zeit für aperiodische Tasks genutzt werden 6 Beurteilung des Ansatzes 6.1 Vorteile Einfaches Konzept Abhängigkeiten und Vorrang können beim offline-scheduling leicht berücksichtigt werden Einsatz komplexer Algorithmen möglich, da Einsatz vor Laufzeit 8

9 Keine Synchronisationsmechanismen nötig, keine Deadlocks Spezielle Anforderungen (z. B. geringe Variationen der Antwortzeit) können berücksichtigt werden Wenig Overhead durch Kommunikation und Kontextwechsel bei großer Frame Size Relativ einfache Validierung und Tests durch Simulation Anomalien der event-driven strategies (wie z. B. Prioritätenumkehr) können nicht auftreten Überprüfung des Status von bestimmten Jobs durch den Scheduler an den Frame-Grenzen frühzeitige Erkennung von Fehlverhalten frühzeitige Maßnahmen 6.2 Nachteile Starres Konzept Veränderung des Systems schwerfällig Kleine Veränderung an den Parametern des Systems verlangt oft eine Neukonstruktion des Ausführungsplans Eignung für Systeme, die nach ihrer Konstruktion selten verändert werden Parameter der Jobs müssen bei Release bekannt sein Release Times aller periodischen Jobs muss fix sein (kein Jitter ) Kombinationen aller periodischen Tasks müssen im Voraus für die Planerstellung bekannt sein 7 Literaturquellen Jane W. S. Liu, Real-time systems, Prentice-Hall, 2000, New Jersey Hermann Kopetz, Real-time systems: design principles for distributed embedded applications, Kluwer Academic Publishers, 2004, Norwell Michael Mächtel, Echtzeitsysteme - Script zur Vorlesung an der FH München, 2004 Robert Baumgartl, TU Chemnitz, Lehrveranstaltung Echtzeitsysteme, 2004 Ricardo Bettati, Texas A & M University, Real-Time Systems, 2001 Dewi Jones, University of Wales, Slides on Real-Time System Scheduling, 2004 Claude Hamann, TU Dresden, Schedulingtheorie, 2004 Colin Perkins, University of Glasgow, Real-Time and Embedded Systems, 2004 Byung Kook Kim, Korea Advanced Institute of Science and Technology, Real-Time Control,