Scheduling - Professur Betriebssysteme
Transcription
Scheduling - Professur Betriebssysteme
Echtzeitsysteme – Scheduling 3.1 Einführung Echtzeitsysteme Sommersemester 2016 3.1 Einführung Scheduling Echtzeitsysteme Scheduling Aufteilung von Ressourcen an konkurrierende Verbraucher“. ” 3. Kapitel ▸ Scheduling ▸ Wichtigste Ressource: CPU Andere mögliche Ressourcen: ▸ Prof. Matthias Werner ▸ Professur Betriebssysteme ▸ ▸ Speicher Festplatte Busse ... SoSe 2016 ⋅ M. Werner Echtzeitsysteme – Scheduling 3.1 Einführung 2 / 64 osg.informatik.tu-chemnitz.de Echtzeitsysteme – Scheduling 3.1 Einführung P2 P3 ... P1 ... Noch Wiederholung: Prozess als virtueller Prozessor ... Wiederholung: Prozessesbegriff ▸ Sequenz von Anweisungen ▸ Benötigt Betriebsmittel (Ressourcen), z.B. Speicher, Geräte, Dateien usw. Besitzt Zustand ▸ virtuelle CPU Px Mikrozustand: Gesamtheit aller dem Prozess gehörenden Betriebsmittel(zustände) (inkl. Prozessorzustand) Makrozustand: M ∈ {bereit, aktiv, wartend} Transformation ... ▸ ... Identifikator ... virtuelle CPU ▸ ▸ virtuelle CPU ... Abstraktion: Programm in Abarbeitung“ ” ▸ ... Prozess Mehrere Prozesse können gleichzeitig existieren á parallele oder nebenläufige Prozesse reale CPU SoSe 2016 ⋅ M. Werner 3 / 64 osg.informatik.tu-chemnitz.de SoSe 2016 ⋅ M. Werner 4 / 64 osg.informatik.tu-chemnitz.de Echtzeitsysteme – Scheduling 3.1 Einführung Echtzeitsysteme – Scheduling 3.1 Einführung Noch Wiederholung: Prozesszustände Ziele ▸ aktiv Prozess wird abgearbeitet (besitzt alle zum Fortschritt nötigen Ressourcen) Klassische Scheduling-Ziele sind: ▸ ▸ ▸ bereit Prozess besitzt alle zum Fortschritt nötigen (passiven) Ressourcen, wird jedoch gerade nicht abgearbeitet wartend Prozess besitzt nicht alle zum Fortschritt nötigen Ressourcen (diese sind an andere Prozesse vergeben) oder Prozess wartet auf ein Ereignis ▸ ▸ ▸ Ziele können sich widersprechen! ▸ Typische Scheduling-Strategien (Nicht-Echtzeit): (nicht existent) Prozess wurde beendet oder noch nicht gestartet ▸ ▸ ▸ (weitere Subzustände denkbar, hier nicht weiter betrachtet) ▸ ▸ SoSe 2016 ⋅ M. Werner 5 / 64 6 / 64 osg.informatik.tu-chemnitz.de Echtzeitsysteme – Scheduling 3.1 Einführung Ziele in Echtzeitsystemen Task und Job In Echtzeitsystemen: Berücksichtigung von Zeitbedingungen: ▸ ▸ ▸ ▸ ▸ First come first serve (FCFS) Shortest job first (SJF) Round robin (RR) Smallest response ratio (SRR) ... SoSe 2016 ⋅ M. Werner osg.informatik.tu-chemnitz.de Echtzeitsysteme – Scheduling 3.1 Einführung ▸ Hohe Auslastung des Systems Fairness Kein Verhungern (lang anhaltende Verdrängung einzelner Tasks) Antwortverhalten (kurze Reaktionszeit) Hoher Durchsatz (abgearbeitete Prozesse pro Zeiteinheit) Minimierung der Anzahl verpasster Deadlines Minimierung der maximalen Verzögerung Maximierung der Kostenfunktionen ... ▸ Es wird zwischen Tasks und Jobs unterschieden: Job: Schedulingsicht á Einheit, die geplant und ausgeführt wird Task: Programmierersicht á Einheit, die eine Aufgabe löst bzw. eine Funktion ausübt; kann eine Menge von Jobs erzeugen ▸ Im periodischen Taskmodell (Erklärung folgt) werden Jobs i.d.R. als Taskinstanzen aufgefasst ▸ Fall eine Task genau einem Job entspricht, werden die Begriffe synonym gebraucht Wieder können sich Ziele widersprechen T1 D2 D1 T3 T2 D1 SoSe 2016 ⋅ M. Werner T3 T2 T4 T4 D3 T5 T5 D2 D3 7 / 64 D5 D4 T1 D4 D5 osg.informatik.tu-chemnitz.de SoSe 2016 ⋅ M. Werner 8 / 64 osg.informatik.tu-chemnitz.de Echtzeitsysteme – Scheduling 3.1 Einführung Echtzeitsysteme – Scheduling 3.1 Einführung Problem des Echtzeitschedulings Aspekte ▸ ▸ ▸ Konkretisieren das Ziel: ▸ ▸ Gegeben sei eine Menge von Jobs Gesucht wird ein Ausführungsplan (Schedule), der es ermöglicht, dass alle Jobs immer ihre Zeitbedingungen (meist: Deadline) einhalten á Schedule ist ausführbar (auch: brauchbar, feasible) ▸ ▸ ▸ Allgemein: Problem ist N P ▸ ▸ Unter bestimmten Einschränkungen gibt es jedoch einfache Algorithmen, die das Problem lösen ▸ ▸ ▸ SoSe 2016 ⋅ M. Werner 9 / 64 SoSe 2016 ⋅ M. Werner osg.informatik.tu-chemnitz.de Echtzeitsysteme – Scheduling 3.1 Einführung 10 / 64 Echtzeit-Scheduling Allgemeine Parameter eines Jobs ▸ release time tr oder r: Zeitpunkt, ab dem ein Job ausgeführt werden kann ▸ starting time ts : Zeitpunkt des Starts eines Jobs ▸ completion time tc : Zeitpunkt der Komplettierung eines Jobs ▸ deadline td oder D: Zeitpunkt, bis zu dem ein Job beendet sein muss (absolut oder relativ) Job ist aktiv tr on-line ts Timeline ohne Prio. Round Robin osg.informatik.tu-chemnitz.de Echtzeitsysteme – Scheduling 3.1 Einführung Häufige Schedulingverfahren in Echtzeitscheduling off-line Zeitpunkt des Schedulings ( Wann wird geplant?“) ” á on-line oder off-line Unterbrechbarkeit ( Kann einem Prozess der Prozessor entzogen werden?“) ” á Wir nehmen i.d.R. an, dass Prozesse unterbrochen werden können Zeit- oder ereignissgesteuert á betrachten beides Nutzung von Prioritäten (keine, fest, variabel) á betrachten alle Varianten Anzahl der Prozessoren á 1 (bis auf weiters) Migration á keine Taskmodell á periodisches Taskmodell Berücksichtigung von Abhängigkeiten á nächstes Kapitel statische Prio. RMS DMS tc td te dynamische Prio. EDF LST tresp Zeitspannen deutsche Bezeichnung Symbol execution time response time laxity1 Ausführungszeit Antwortzeit Zeitfenster te oder e tresp ttard = tc − tr = td − tc 1 auch: slack time oder (insbesondere wenn negativ): Verspätung (tardiness) SoSe 2016 ⋅ M. Werner 11 / 64 osg.informatik.tu-chemnitz.de SoSe 2016 ⋅ M. Werner 12 / 64 osg.informatik.tu-chemnitz.de Echtzeitsysteme – Scheduling 3.1 Einführung Echtzeitsysteme – Scheduling 3.1 Einführung Scheduling für periodische Tasks ▸ Modell: ▸ ▸ ▸ Scheduling für periodische Tasks (Forts.) Standardzyklus: Sensor lesen – Wert verarbeiten – Effektor steuern (á Kapitel 2) Mehrere Standardzyklen sind durch einen Prozessor zu bedienen ▸ Annahmen (Standardannahmen): ▸ ▸ ▸ ▸ ▸ Es werden meist drei verschiedene Arten von Tasks unterschieden: ▸ Alle Tasks treten periodisch auf (Jobs á Taskinstanzen) Jeder Job ist stets unterbrechbar, und die Unterbrechungskosten sind vernachlässigbar Jobs sind voneinander unabhängig, alle Ressourcen sind hinreichend vorhanden Nur ein Prozessor Deadline = Periodenlänge ▸ ▸ periodisch: periodische Aktivierung der Jobs einer Task aperiodisch: nichtperiodische Aktivierung der Jobs einer Task; die Zwischenankunftszeit zweier Jobs ist nicht nach unten beschränkt sporadisch: nichtperiodische Aktivierung der Jobs einer Task; maximale Ankunftsrate der Jobs ist beschränkt Merke Die Standardannahmen sind keine Annahmen über das Schedulingverfahren. SoSe 2016 ⋅ M. Werner 13 / 64 SoSe 2016 ⋅ M. Werner osg.informatik.tu-chemnitz.de Echtzeitsysteme – Scheduling 3.1 Einführung Last Periodische Tasks werden häufig als Tupel notiert: ▸ ▸ ▸ Tasks erzeugen auf einen Prozessor eine gewisse Last (load, utilization) Lastbegriff ist schwierig im Nicht-Echtzeit-Bereich Unter Standardannahmen einfache Definition: Ti (φi , Pi , ei , Di ) ▸ Bedeutung der Parameter, jeweils der i. Task: ▸ ▸ ▸ ▸ φi : Phase (um versetzte Startzeiten zu erlauben) Pi : Periode ei : Bedienzeit Di : Deadline ▸ Da meist φi = 0 und Di = Pi wird deren Angabe häufig fortgelassen ▸ Jobs erben“ Parameter ihrer Task ” Analoge Beschreibung für sporadische Tasks, aber PeriodePi ist minimale Zwischenankunftszeit (minimal interarrival time) der Jobs SoSe 2016 ⋅ M. Werner 15 / 64 ei Pi Last einer Task: Ui = Gesamtlast einer Taskmenge: U = ∑ Ui = ∑ Peii i ▸ ▸ ▸ osg.informatik.tu-chemnitz.de Echtzeitsysteme – Scheduling 3.1 Einführung Beschreibung periodischer Tasks ▸ 14 / 64 osg.informatik.tu-chemnitz.de i ei : Ausführungszeit Pi : Periode ▸ Unter Standardannahmen: Pi = Di ▸ Eine Last von 1 bedeutet, dass der Prozessor niemals unbeschäftigt (idle) ist ▸ Merke: Lasten > 1 sind nicht ausführbar SoSe 2016 ⋅ M. Werner 16 / 64 osg.informatik.tu-chemnitz.de Echtzeitsysteme – Scheduling 3.1 Einführung Echtzeitsysteme – Scheduling 3.1 Einführung Konzept: Kritischer Zeitpunkt und kritisches Intervall ▸ Ein kritischer Zeitpunkt ist die Ankunftszeit eines Jobs, bei dem er die längste Antwortzeit hat ▸ Ein kritisches Intervall ist die Zeit wischen dem kritischen Zeitpunkt eines Jobs und der Beendigung der entsprechenden Jobausführung Konzept: Schwere Planbarkeit Eine Menge T ist von einem Schedulingverfahren S schwer zu planen ((most) difficult/hard to schedule), wenn jede Vergrößerung der Rechenzeit irgendeiner Task dazu führt, dass T nicht mehr ausführbar ist ▸ ▸ Merke Für die gleiche Taskmenge kann der gleiche Job bei verschiedenen Schedulingverfahren unterschiedliche kritische Zeitpunkte und Intervalle haben SoSe 2016 ⋅ M. Werner 17 / 64 ▸ Auch in der Literatur: Taskmenge lastet Processor vollständig aus“ (fully utilize) ” Eine volle Auslastung bedeutet nicht, dass der Prozessor niemals unbeschäftigt (idle) ist, oder dass die Last 1 ist Merke: Wenn eine Taskmenge T für ein Schedulingverfahren S schwer planbar ist, muss dies nicht für T bei einem anderen Schedulingverfahren S gelten SoSe 2016 ⋅ M. Werner osg.informatik.tu-chemnitz.de Echtzeitsysteme – Scheduling 3.2 Prioritäten 18 / 64 osg.informatik.tu-chemnitz.de Echtzeitsysteme – Scheduling 3.2 Prioritäten 3.2 Einfache prioritätsbasierte Verfahren Prioritätsbasierte Verfahren Einprozessorsysteme Klassische Verfahren für Einprozessorsysteme, die Prioritäten nutzen, sind u.a.: ▸ Rate Monotonic Scheduling (RMS) (LIU und LAYLAND) ▸ Earliest Deadline First (EDF) ( LIU und LAYLAND) ▸ Least Slack-Time First (LST, auch Minimum Laxity First, MLF) (LEUNG und WHITEHEAD / MOK) Alle prioritätsbasierten Verfahren haben gemeinsam, dass jedem Job eine Prioriät zugewiesen wird Es werden zwei Klassen von prioritätenbasierten Schedulingverfahren unterschieden: ▸ Verfahren mit festen Prioritäten (fixed priority scheduling) á Prioritäten werden a priori festgelegt, für jeden Job einer Task stets gleich ▸ Verfahren mit variablen Prioritäten (variable priority scheduling) á Prioritäten der Jobs können sich ändern Verfahren mit festen Prioritäten sind leichter zu implementieren Bei den genannten Verfahren wird immer der Job mit der augenblicklich höchsten Prioriät ausgeführt SoSe 2016 ⋅ M. Werner 19 / 64 osg.informatik.tu-chemnitz.de SoSe 2016 ⋅ M. Werner 20 / 64 osg.informatik.tu-chemnitz.de Echtzeitsysteme – Scheduling 3.2 Prioritäten Echtzeitsysteme – Scheduling 3.2 Prioritäten Earliest Deadline First (EDF) Beispiel ▸ 2 (periodische) Tasks T1 (2, 0.9) und T2 (5, 2.3) ▸ (Notation: Ti (tp,i , te,i )) J1,1 J1,2 J1,3 J1,4 J1,5 ... ▸ EDF arbeitet mit variablen Prioritäten ▸ Jeder Job erhält eine Priorität entsprechend ihrer Deadline: Ein Job mit einer kürzeren Deadline hat stets eine höhere Priorität als ein Job mit einer längeren Deadline T2 Eine laufbereiter Job mit höherer Priorität unterbricht stets einen Job niederer Priorität ▸ t=0: td,1 = 2, td,2 = 5 ⇒ J1,1 abgearbeitet ▸ t=2: td,1 = 4, td,2 = 5 ⇒ J1,2 abgearbeitet ▸ t=4: td,1 = 6, td,2 = 5 ⇒ J2,1 abgearbeitet ▸ d.h., im Intervall [0, 4) hat T1 die höhere Priorität und im Intervall [4, 5) hat T2 die höhere Priorität ▸ SoSe 2016 ⋅ M. Werner 21 / 64 T1 0 1 2 3 J2,1a 0 1 4 J2,1b 2 3 Echtzeitsysteme – Scheduling 3.2 Prioritäten 6 7 J2,2a 4 SoSe 2016 ⋅ M. Werner osg.informatik.tu-chemnitz.de 5 5 8 9 7 8 22 / 64 t ... J2,2b 6 10 9 10 t osg.informatik.tu-chemnitz.de Echtzeitsysteme – Scheduling 3.2 Prioritäten Optimalität von EDF Beweisskizze für Theorem 3.1 Überführung eines Nicht-EDF-Schedules in ein EDF-Schedule ▸ Austausch der Tasks innerhalb ihrer bisherigen Timeslots (nur Zeitanteile nach der Taskankunft von Ti ) Theorem 3.1 (Optimalität von EDF) Tk Ti Unter den Standardannahmen kann EDF für die Taskmenge T genau dann einen ausführbaren Schedule erzeugen, wenn irgendein ausführbarer Schedule für T existiert. rk Anders gesagt: Wenn irgendein Schedulingverfahren S unter den Standardbedingungen für T einen ausführbaren Schedule erzeugen kann, dann kann EDF das auch Dk Di Tk ▸ Wiederholen für alle Tasks ▸ Verschieben der Idle-Zeiten Tk Tk Tk SoSe 2016 ⋅ M. Werner 23 / 64 osg.informatik.tu-chemnitz.de SoSe 2016 ⋅ M. Werner 24 / 64 Ti Ti osg.informatik.tu-chemnitz.de Echtzeitsysteme – Scheduling 3.2 Prioritäten Echtzeitsysteme – Scheduling 3.2 Prioritäten Schedulingkriterium für EDF Rate Monotonic Scheduling (RMS) Problem: Gibt es ein Kriterium, welches feststellt, ob eine Taskmenge T unter EDF ausführbar ist, ohne dass das Verfahren vollzogen wird? Hinreichende und notwendige Schedulingbedingung für EDF: ▸ RMS arbeitet mit festen Prioritäten Theorem 3.2 (EDF-Schedulingbedingung) ▸ Ein Menge T von n Tasks ist mit EDF unter den Standardannahmen genau dann ausführbar, wenn n ei UT = ∑ ≤1 P i=1 i Task (alle Jobs) erhält eine Priorität reziprok zu ihrer Periode (Deadline) á (Ankunfts-)Rate ▸ Ein Job (laufbereite Tasksinstanz) mit höherer Priorität unterbricht stets ein Job niederer Priorität Mit anderen Worten: EDF ist immer erfolgreich, wenn die Last der Taskmenge kleiner/gleich 1 ist SoSe 2016 ⋅ M. Werner 25 / 64 SoSe 2016 ⋅ M. Werner osg.informatik.tu-chemnitz.de Echtzeitsysteme – Scheduling 3.2 Prioritäten RMS vs. EDF ▸ Taskset: T1 (4, 1), T2 (5, 2), T3 (20, 5) ▸ T3 ... T2 ... T1 ... J11 0 osg.informatik.tu-chemnitz.de Echtzeitsysteme – Scheduling 3.2 Prioritäten Beispiel ▸ 26 / 64 J21 J31 J12 J22 2 4 6 SoSe 2016 ⋅ M. Werner J32 J13 J33 8 J23 10 27 / 64 J14 12 J34 14 J24 J15 J25 16 18 ′ J11 20 ▸ ▸ Task 1: P1 = 6, e1 = 3 Task 2: P2 = 10, e2 = 5 Task 1 hat höhere RMS-Priorität Ausführbar mit EDF M ... t osg.informatik.tu-chemnitz.de SoSe 2016 ⋅ M. Werner 28 / 64 osg.informatik.tu-chemnitz.de Echtzeitsysteme – Scheduling 3.2 Prioritäten Echtzeitsysteme – Scheduling 3.2 Prioritäten Optimalität von RMS Beweis von Theorem 3.3 ▸ M sei Fixed-Priority-Verfahren, das ein Taskmenge T ausführbar plant; der entstehende Schedule sei S ▸ Überführung von S ▸ In S gelte pj = pi + 1 bei Pj > Pi (px bezeichne Prioritäten) Austausch von pi und pj lässt den Schedule ausführbar: Theorem 3.3 (Optimalität von RMS) Unter den Standardannahmen kann RMS für die Taskmenge T genau dann einen ausführbaren Schedule erzeugen, wenn irgendein anderes Fixed-prioriy-Verfahren einen ausführbaren Schedule für T findet. ▸ ▸ Insgesamt ist RMS nicht optimal, da es Taskmengen geben kann, die mit RMS nicht ausführbar sind, wohl aber mit anderen Schedulingverfahren M ▸ Aber: M kann kein Fixed-Priority-Verfahren sein SoSe 2016 ⋅ M. Werner 29 / 64 ▸ Fall 2: J1 wird nicht zu r2 ausgeführt, d.h. 0 < r1 ≤ P2 − e2 Der kritische Augenblick ist für jeden Job in RMS, wenn er zeitgleich mit allen höherpriorisierten Jobs ankommt. Beweis für zwei Tasks. Sei r2 = 0 osg.informatik.tu-chemnitz.de Kritischer Zeitpunkt bei RMS (Forts.) Theorem 3.4 (Kritischer Zeitpunkt bei RMS) ▸ 30 / 64 Echtzeitsysteme – Scheduling 3.2 Prioritäten Kritischer Zeitpunkt bei RMS Sei T: T1 , T2 mit P1 < P2 . Wiederholen, bis S zum RMS-Schedule geworden ist SoSe 2016 ⋅ M. Werner osg.informatik.tu-chemnitz.de Echtzeitsysteme – Scheduling 3.2 Prioritäten ▸ Nur Stellen interessant, an denen Ji von Jj an Ausführung gehindert wird. Da Deadline von Jj offensichtlich nach Deadline von Ji , können Taskstückchen vertauscht werden ▸ 1 Dann ist tc,2 = e2 + ⌈ Pe21−r ⌉ e1 −e1 ▸ Alles außer r1 ist konstant ▸ tc,2 ist am größten, wenn r1 am kleinsten ist ▸ ⇒ r1 = 0. Ähnliche Argumentation bei mehr als 2 Jobs. Fall 1: J1 wird zu r2 = 0 ausgeführt, d.h., −e1 < r1 ≤ 0. ▸ 2 Dann ist tc,2 = e2 + (e1 − ∣r1 ∣) + (⌈ P1e−e ⌉ − 1) e1 1 ▸ Alles außer r1 ist konstant: tc,2 = C − ∣r1 ∣ ▸ Dies ist am größten, wenn ∣r1 ∣ am kleinsten ist ⇒ r1 = 0. SoSe 2016 ⋅ M. Werner 31 / 64 Verallgemeinerung Für Festprioritätsverfahren genügt den Fall zu betrachten, wenn alle Jobs aller Tasks gleichzeitig ankommen. osg.informatik.tu-chemnitz.de SoSe 2016 ⋅ M. Werner 32 / 64 osg.informatik.tu-chemnitz.de Echtzeitsysteme – Scheduling 3.2 Prioritäten Echtzeitsysteme – Scheduling 3.2 Prioritäten Schedulingkriterium für RMS ▸ Grenzwert für Lastschranke Wieder: Gibt es ein Kriterium, welches feststellt, ob eine Taskmenge T unter RMS ausführbar ist, ohne dass das Verfahren vollzogen wird? 1 U∞ Theorem 3.5 (Schedulingkriterium für RMS) = lim n(2 n − 1) n→∞ 1 Ein Menge T von n Tasks ist mit RMS unter den Standardbedingungen immer dann ausführbar, wenn = lim 2n − 1 1 n n→∞ 1 n = U ≤ n(2 − 1) 1 d (2 n − 1) dn lim d 1 n→∞ ( ) dn n 1 ▸ ▸ Untere Schranke der obere Grenze Hinreichend, aber nicht notwendig n U 1 1, 0 2 0, 828 SoSe 2016 ⋅ M. Werner = = ln 2 5 0, 743 10 0, 718 50 0, 698 33 / 64 U∞ 100 0, 695 ▸ Tatsächliche Grenze liegt meist viel besser Statistischer Mittelwert liegt etwa bei 0,88 ▸ Genauerer Schedulingtests mit Analyse der Zeitanforderungen (Time-Demand Analysis) ▸ Time-Demand Analysis (TDA) wurde von LEHOCZKY, SHA und DING 1989 [LSD89] vorgestellt: TDA kann als Test für alle Fixed-Priority-Schedulingverfahren für periodische Taskmengen angewandt werden, wenn die Deadline nicht größer als die Periode ist. SoSe 2016 ⋅ M. Werner osg.informatik.tu-chemnitz.de Zeitanforderungsfunktion Die Zeitanforderungsfunktion (time demand function wi (t)) gibt die angeforderte CPU-Zeit der Jobs einer Task Ti bis zum Zeitpunkt t an ▸ ▸ 34 / 64 Echtzeitsysteme – Scheduling 3.2 Prioritäten RMS-Theorem (Theorem 3.5) gibt nur eine Schranke an ▸ ≈ 0, 693 SoSe 2016 ⋅ M. Werner osg.informatik.tu-chemnitz.de Zeitforderungsanalyse ▸ − n12 n→∞ Echtzeitsysteme – Scheduling 3.2 Prioritäten ▸ lim 2 n ⋅ ln 2 ⋅ − n12 35 / 64 osg.informatik.tu-chemnitz.de ▸ Dabei wird die Verdrängung durch höherpriore Tasks berücksichtigt wi (t) ist wie folgt definiert: i−1 wi (t) = ei + ∑ ⌈ k=1 ▸ t ⌉ ⋅ ek Pk Tasks sind nach Prioritäten geordnet, T1 hat die höchste Priorität SoSe 2016 ⋅ M. Werner 36 / 64 osg.informatik.tu-chemnitz.de Echtzeitsysteme – Scheduling 3.2 Prioritäten Echtzeitsysteme – Scheduling 3.2 Prioritäten Schedulingbedingung nach TDA Iterationsverfahren ▸ Im Theorem 3.6 kommt in der Ungleichung wi (t) ≤ t auf beiden Seiten t vor á Weg zur Bestimmung von t gesucht. ▸ Lösung über ein Iterationsverfahren Theorem 3.6 (TDA-Theorem) Eine Menge T von unterbrechbaren, periodischen und unabhängigen Tasks ist mit einem Fixed-Priority-Verfahren S ausführbar, wenn ▸ ∀i, ∃t, 0 < t ≤ min(Di , Pi ), wi (t) ≤ t Mit anderen Worten: Für jede Task muss es einen Zeitpunkt in seiner Periode oder Deadline geben, zu dem die ihre Zeitanforderung nicht höher ist, als die verstrichene Zeit. ▸ (0) Startwert: ti ▸ Iteration: ▸ Abbruch bei: (l) ▸ ti ▸ ti = ei (l+1) ti (l) = w(ti ) > Pi á Task ist nicht ausführbar (l+1) = ti (l) ≤ Pi á Task ist ausführbar Anmerkungen i ▸ ▸ Der Startwert ist egal, aber der kleinste sinnvolle Wert ist ∑ ej (Tasks sind nach ▸ Prioritäten geordnet) Im der Originalveröffentlichung [LSD89] werden zuerst die Änderungspunkte für wi (t) berechnet und dort einzeln die Ungleichung geprüft j=1 Unter den Standardannahmen gilt: Di = Pi á keine Minimumbildung nötig SoSe 2016 ⋅ M. Werner 37 / 64 SoSe 2016 ⋅ M. Werner osg.informatik.tu-chemnitz.de Echtzeitsysteme – Scheduling 3.2 Prioritäten Graphische Lösung ▸ 3 Tasks: T1 = (3, 1) ▸ Iteration für T3 : osg.informatik.tu-chemnitz.de Echtzeitsysteme – Scheduling 3.2 Prioritäten Beispiel für Iterationsverfahren ▸ 38 / 64 Statt des Iterationsverfahrens kann die Analyse auch grafisch erfolgen 440 T2 = (5, 1.5) T3 = (7, 1.25) wi(t) 420 400 380 360 (0) t3 = te,3 = 1.25 1.25 1.25 ⌉+⌈ ⌉ ⋅ 1.5 = 3.75 t(1) = 1.25 + ⌈ 3 5 3.75 3.75 (2) t3 = 1.25 + ⌈ ⌉+⌈ ⌉ ⋅ 1.5 = 4.75 3 5 4.75 4.75 (3) t3 = 1.25 + ⌈ ⌉+⌈ ⌉ ⋅ 1.5 = 4.75 3 5 (3) ▸ t 3 = (2) t3 340 320 T1 T2 T3 T4 ei 20 30 80 100 Pi 100 150 210 400 300 280 T4 260 240 220 200 180 T3 160 140 120 100 = 4.75 < P3 = 7 á T3 ist ausführbar T2 80 60 40 20 T1 t 0 50 SoSe 2016 ⋅ M. Werner 39 / 64 osg.informatik.tu-chemnitz.de SoSe 2016 ⋅ M. Werner 100 40 / 64 150 200 250 300 350 400 osg.informatik.tu-chemnitz.de Echtzeitsysteme – Scheduling 3.2 Prioritäten Echtzeitsysteme – Scheduling 3.2 Prioritäten Variationen von RMS Harmonisches RMS ▸ Idee: Einschränkung – nicht mehr alle Taskmengen sind zugelassen ▸ RMS ist eines der am häufigsten genutzten Schedulingverfahren Definition 3.7 (Harmonische Taskmengen) ▸ Es existieren Variationen, die die Leistungsfähigkeit (in unterschiedlichen Parametern) verbessern Betrachten hier: Eine Menge von Tasks T nennt man einfach periodisch oder harmonisch, wenn für jedes Paar von Tasks Ti und Tj mit Pi ≤ Pj gilt, dass Pj ein ganzzahliges Vielfache von Pi ist, also Pj = k, k ∈ G ∀i, j, Pj ≥ Pi , Pi ▸ ▸ ▸ Harmonisches RMS DMS: Deadline Monotonic Scheduling ▸ SoSe 2016 ⋅ M. Werner 41 / 64 Ein RMS, das ausschließlich mit einfach periodischen Taskmengen benutzt wird, nennt man harmonisches RMS SoSe 2016 ⋅ M. Werner osg.informatik.tu-chemnitz.de Echtzeitsysteme – Scheduling 3.2 Prioritäten Theorem 3.8 Eine harmonische Taskmenge T ist unter RMS genau dann ausführbar, wenn U =∑ T ei ≤1 Pi Deadline Monotonic Scheduling ▸ Idee: Erweiterung – Deadline ist nicht immer Periode ▸ Deadline Monotonic Scheduling: Prioritäten reziprok zu periodischer relativer Deadline [Aud+93] ▸ ∀i, Di = Pi á DMS wird zu RMS ▸ Hinreichend und notwendig ▸ Beweis folgt aus TDA á Übung SoSe 2016 ⋅ M. Werner osg.informatik.tu-chemnitz.de Echtzeitsysteme – Scheduling 3.2 Prioritäten Schedulebarkeit von harmonischen Taskmengen ▸ 42 / 64 ▸ ▸ 43 / 64 osg.informatik.tu-chemnitz.de Hinreichend: ∀i, Di = c ⋅ Pi , c = const ∃i, Di ≠ Pi á DMS ist besser als RMS D.h. DMS findet u.U. ausführbaren Schedule, wenn RMS dies nicht kann SoSe 2016 ⋅ M. Werner 44 / 64 osg.informatik.tu-chemnitz.de Echtzeitsysteme – Scheduling 3.2 Prioritäten Echtzeitsysteme – Scheduling 3.2 Prioritäten RMS vs. DMS: Beispiel ▸ Least Slacktime First 3 Tasks, Ti (tφ,i , Pi , ei , Di ) ∶ T1 (50, 50, 25, 100), T2 (0, 62.5, 10, 20), T3 (0, 125, 25, 50) ▸ J1,2 T1 0 ▸ ▸ 50 62,5 85 ▸ 125 100 0 72.5 50 135 100 185 150 J2,3 DMS: T2 10 Es gibt noch eine Reihe weiterer prioritätsbasierter Verfahren Beispiel: Least Slacktime First (LSF) 200 225 250 t ▸ ▸ 197.5 150 250 200 Auch genannt: minimum laxity first (MLF) Dynamisch, kürzere Slacktime = höhere Priorität (Unter Standardbedingungen) gleichfähig wie EDF t Slacktime Bedienzeit J2,3 T3 35 0 50 160 100 150 200 250 t Task T ▸ 250 ... t 200 250 t 200 250 t RMS: T1 0 50 75 100 125 150 175 200 225 t Startzeit Ankunftszeit T2 0 10 50 85 100 135 197.5 150 Deadline verletzt! T3 0 35 50 100 SoSe 2016 ⋅ M. Werner 150 Deadline verletzt! 45 / 64 ▸ Deadline Unpraktisch (warum?) und deshalb hier nicht relevant SoSe 2016 ⋅ M. Werner osg.informatik.tu-chemnitz.de Echtzeitsysteme – Scheduling 3.3 Zeitsteuerung 46 / 64 osg.informatik.tu-chemnitz.de Echtzeitsysteme – Scheduling 3.3 Zeitsteuerung 3.3 Zeitgesteuerte Verfahren Ad-hoc-Beispiel Timeline Scheduling ▸ 4 periodische Tasks Ti (Pi , ei ): ▸ ▸ Bisher waren alle Verfahren online-Verfahren ▸ Häufig kommen auch offline-Verfahren vor ▸ Betrachten hier: Timeline Scheduling (häufig auch einfach Cyclic Scheduling oder Cyclic Executive Scheduling genannt) Grundsätzliche Idee: ▸ ▸ ▸ ▸ ▸ ▸ ▸ Periodisches Taskmodell, Taskmenge T = {T1 , . . . , Tn } Schedule einer Menge T mit n Task besteht aus aneinandergereihten Segmenten der Länge H = kgV(Pi ), i = 1, 2, . . . n H wird Hyperperiode genannt SoSe 2016 ⋅ M. Werner 47 / 64 osg.informatik.tu-chemnitz.de T1 (4, 1) T2 (5, 1.8) T3 (20, 1) T4 (20, 2) 1 4 1.8 5 1 20 ▸ Last: U = ▸ Ausführbarer Schedule: + T1 T3 T2 + T1 + 2 20 T4 = 0.76 T2 T1 T2 T1 T1 T2 T1 ... 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 t ▸ Die Schedulingzeitpunkte können in einer Tabelle abgelegt werden ▸ Durch Scheduling von Idlezeiten können ggf. Nichtechtzeit-Jobs eingefügt werden SoSe 2016 ⋅ M. Werner 48 / 64 osg.informatik.tu-chemnitz.de Echtzeitsysteme – Scheduling 3.3 Zeitsteuerung Echtzeitsysteme – Scheduling 3.3 Zeitsteuerung Implementierung ▸ ▸ Minor Cycles Tabelleneinträge: (0, T1 ) (1, T3 ) (2, T2 ) (4, T1 ) (6, T4 ) . . . Initialisierung: ▸ Idee: Unterteilung des Schedules in gleichlange Frames (auch: minor cycles) ▸ ▸ ▸ 1 2 3 4 5 6 7 8 Timerinterrupt auf t0 gesetzt k=0 ▸ ▸ Innerhalb vom Frames werden Jobs nacheinander ausgeführt Scheduler wird nur am Frameanfang aufgerufen á weniger Overhead Timer mit konstanter Periode á keine Reprogrammierung while ( true ) { acknowledge Timerinterrupt ; T := T[k ]; k := ++k mod(N); /* nächster Tabelleneintrag */ set Timer to nä chster Taskstart ; execute T; sleep ; } ▸ H t 49 / 64 t + 2f t + 3f t+H 1 Frame Aktivierung des Schedulers nach jedem Job á ungünstig, insbesondere bei sehr kurzen Jobs SoSe 2016 ⋅ M. Werner t+f ▸ Ist Jobüberlauf möglich, muss er an Framegrenze erkannt werden SoSe 2016 ⋅ M. Werner osg.informatik.tu-chemnitz.de Echtzeitsysteme – Scheduling 3.3 Zeitsteuerung 50 / 64 osg.informatik.tu-chemnitz.de Echtzeitsysteme – Scheduling 3.3 Zeitsteuerung Framegröße Bedingung 3 ▸ Job wird laufbereit a Zeiteinheiten vor dem nächsten Frame Frame k ▸ Frage: Wie groß soll dann Framelänge f sein? ▸ Es gibt mehrere Aspekte bei von f (frame size constraints) t+f t tr 1. Keine Überschreitung der Framegrenze bei Jobausführung á f ≥ max(ei ) i Frame k + 1 t + 2f a Für Pi ≠ f á a variiert 3. f sollte so klein sein, dass zwischen tr und td jedes Jobs mindestens ein kompletter Frame liegt á nähere Betrachtung folglich: Minimaler Abstand tr − t (falls irgendwann tr = t galt): 51 / 64 osg.informatik.tu-chemnitz.de a+f ≤D (1) tr − t ≥ ggT(f, P ) (2) f − ggT(f, P ) + f ≤ D eingesetzt in (1): SoSe 2016 ⋅ M. Werner tr + P a ≤ f − ggT(f, P ) 2f − ggT (f, Pi ) ≤ td,i SoSe 2016 ⋅ M. Werner t + 3f tr + D Es muss gelten: 2. Minimierung der Schedullänge á f sollte ganzzahliger Teiler der Hyperperiode H sein, H = kgV(Pi ) Frame k + 2 52 / 64 ∀i, 1 ≤ i ≤ n (3) osg.informatik.tu-chemnitz.de Echtzeitsysteme – Scheduling 3.3 Zeitsteuerung Echtzeitsysteme – Scheduling 3.3 Zeitsteuerung Beispiel ▸ Job Slicing 3 Periodische Tasks: i 1 2 3 ▸ Pi 15 20 22 Di 14 26 22 ei 1 2 3 ▸ Betrachten folgendes Beispiel: T1 (1, 4), T2 (2, 5) und T (5, 20) ▸ Laut Constraint 1: f ≥ 5, aber laut Constraint 3: f ≤ 4 á Problem ▸ Lösung: Zerlegung von T3 in J3,1 (1, 20), J3,2 (3, 20) und J3,3 (1, 20) á Jobslicing (manchmal auch: Time Slicing) ▸ Constraints: 1. f ≥ 3 2. f ∈ {2, 4, 5, 10, 20} 3. f ≤ 4 J3,1 Welches sind geeignete Framegrößen? ▸ H = kgV(15, 20, 22) = 660 1. f ≥ 3 2. f ∈ {2, 3, 4, 5, 6, 10, 11, 12, 15, 20, 22, . . .} 3. f ≤ 6 ▸ 0 ▸ 53 / 64 osg.informatik.tu-chemnitz.de ▸ ▸ ▸ ▸ ▸ 12 T1 T2 16 T1 ... 20 21 t SoSe 2016 ⋅ M. Werner 54 / 64 osg.informatik.tu-chemnitz.de 1. Konstruktion des Graphen Händisch (scharfes Hinsehen ) Round-Robin (funktioniert nur bedingt) Branch-and-Bound (z.B. [XP90] ) Andere Suchverfahren Rückführung auf Flussproblem in Graphen (nach [Bla87] ) ▸ ▸ ▸ ▸ für jeden Job und jedes Frame einen Knoten, zusätzlich Quelle Q und Senke S von Q zu jedem Job Ji eine Kante mit Kapazität ei von jedem Frame zu S eine Kante mit Kapazität f (Framegröße) von Job zu Frame eine Kante mit Kapazität f gdw. Job in Frame abgearbeitet werden kann (Timingconstraints) 2. Ermittlung des maximalen Flusses Φ (z.B. nach FORD UND FULKERSON) 3. Wenn Φ ≥ ∑ ei á Schedule entspricht der Abbildung von Flüssen auf Frames Wir betrachten letzteren Ansatz: Idee i Ein Job Ji kann nur in den Frames geplant werden, deren Startzeit größer oder gleich tr,i ist und die nicht später enden als td,i . SoSe 2016 ⋅ M. Werner 8 T1 T2 Scheduling als Fluss Wie werden nur Jobs auf die Frames verteilt? Verschiedene Verfahren: ▸ J3,2 Echtzeitsysteme – Scheduling 3.3 Zeitsteuerung Scheduleerstellung ▸ 4 T1 Nachteil: (wieder) mehr Kontextwechsel Echtzeitsysteme – Scheduling 3.3 Zeitsteuerung ▸ J3,3 H T1 T2 T1 T2 á f ∈ {3, 4, 5, 6} SoSe 2016 ⋅ M. Werner ⎫ ⎪ ⎪ ⎪ ⎬ ⇒ f =4 ⎪ ⎪ ⎪ ⎭ 55 / 64 osg.informatik.tu-chemnitz.de Sonst: Kein Schedule möglich SoSe 2016 ⋅ M. Werner 56 / 64 osg.informatik.tu-chemnitz.de Echtzeitsysteme – Scheduling 3.3 Zeitsteuerung Echtzeitsysteme – Scheduling 3.3 Zeitsteuerung Beispiel Beispiel (Forts.) Frames Jobs ▸ Zwei Tasks: T1 (4, 3) und T2 (6, 1.5) ▸ H = 12, f = 4 á 3 Frames pro Hyperperiode ▸ Jobs in H: ▸ Jobs J111 f1 [0, 2), f2 [2, 4), f3 [4, 6), f4 [6, 8), f5 [8, 10), f6 [10, 12) Dekomposition: Frames f1 2; 2 ▸ J1,1 (0, 4, 3) 4; 3 J1,2 (4, 8, 3) T1 → J1,1 (0, 4, 3), J1,2 (4, 8, 3) J1,3 (8, 12, 3) T2 → J2,1 (0, 6, 1.5), J2,2 (6, 12, 1.5) ▸ ▸ Lösung: Jobslicing, f = 2 ▸ 6 Frames: f1 [0, 4) J1,3 (8, 12, 3) 3; 3 4; 3 f2 [4, 8) 3; 3 ▸ max Fluss: Φ = 11 aber: ∑ ei = 12 4; 4 S 4; 3 1.5; 1 1.5; 1 J2,1 (0, 6, 1.5) á Φ < ∑ ei i 4; 3 J132 (10, 12, 1) J121 2; 2 2; 0 2; 1 1; 1 2; 2 Q ▸ J2,1 und J2,2 bleiben unverändert J122 f3 2; 1.5 J2,2 (6, 12, 1.5) 2; 2 2; 0.5 2; 2 1; 1 2; 2 2; 1 f4 J131 S 2; 2 2; 0.5 2; 2 J132 ▸ max Fluss: Φ = 12 und ∑ ei = 12 i f3 [8, 12) 4; 1 ▸ Mit f = 4 kein Schedule möglich ▸ J1,3 (8, 12, 3) → J132 (8, 12, 2), f2 1; 1 4; 4 i 2; 2 ▸ J1,2 (4, 8, 3) → J121 (4, 8, 2), J122 (6, 8, 1) 4; 1 2; 0 2; 1 ▸ J1,2 (0, 4, 3) → J111 (0, 4, 2), J112 (2, 4, 1) 3; 3 Q J112 2; 2 2; 0.5 2; 0 1.5; 1.5 á Scheduling erfolgreich f5 2; 2 2; 1 ▸ Die Flüsse zu den Frames geben Schedule an 1.5; 1.5 J21 2; 0 2; 1 J22 SoSe 2016 ⋅ M. Werner 57 / 64 osg.informatik.tu-chemnitz.de SoSe 2016 ⋅ M. Werner Echtzeitsysteme – Scheduling 3.3 Zeitsteuerung Beispiel (Forts.) osg.informatik.tu-chemnitz.de Echtzeitsysteme – Scheduling Anhang A: Literatur Anhang A: Literatur Frames Jobs Ergebnis: 58 / 64 f6 f1 J111 2; 2 J112 2; 0 f2 2; 1 J121 2; 2 2; 2 2; 0 2; 1 1; 1 Q 2; 1.5 J122 2; 2 1; 1 2; 2 2; 1 f4 S 2; 2 2; 0.5 1; 1 [Lui00] Jane W. S. Lui. Real-Time Systems. Prentice Hall, 2000, Kapitel 3 – 6 [But05] Giorgio C. Buttazzo. Hard Real-Time Computing Systems. Springer, 2005, Kapitel 4 [KS97] C. M. Krishna und Kang G. Shin. Real-Time Systems. McGraw-Hill, 1997, Abschnitte 3.2.1 und 3.2.2 [LL73] Chung Laung Liu und James Layland. Scheduling Algorithms for Multiprogramming in a ” Hard Real-Time Environment“. In: Journal of ACM 20.1 (1973), S. 46–61 2; 2 2; 0.5 J131 2; 2 f3 2; 2 J132 f5 2; 2 2; 0 1.5; 1.5 2; 0.5 2; 2 2; 1 1.5; 1.5 J21 2; 0 2; 1 J22 J111 0 f1 J112 J21 2 SoSe 2016 ⋅ M. Werner f2 f6 J21 J121 J22 J121 4 f3 J122 6 59 / 64 f4 J131 8 J132 J22 ... f5 10 f6 12 t osg.informatik.tu-chemnitz.de SoSe 2016 ⋅ M. Werner 60 / 64 osg.informatik.tu-chemnitz.de Echtzeitsysteme – Scheduling Anhang A: Literatur Echtzeitsysteme – Scheduling Anhang B: Flußproblem Anhang B: Flußproblem Literatur (Forts.) Algorithmus von FORD und FULKERSON [LSD89] John P. Lehoczky, Lui Sha und Y. Ding. The Rate Monotonic Scheduling Algorithm: Exact ” Characterization and Average Case Behavior“. In: IEEE Real-Time Systems Symposium. 1989, S. 166–171 [Aud+93] N. Audsley u. a. Applying New Scheduling Theory to Static Priority Pre-Emptive ” Scheduling“. In: Software Engineering Journal 8 (1993), S. 284–292 [Bla87] Jacek Blazewicz. Selected Topics in Scheduling Theory“. In: Annals of Discrete ” Mathematics 31 (1987), S. 1–60 SoSe 2016 ⋅ M. Werner 61 / 64 Anhang: Algorithmus von FORD und FULKERSON ▸ Nach LESTER RANDOLPH FORD JR und DELBERT RAY FULKERSON, 1956 ▸ Gegeben sei ein Graph N = (V, E, q, s, c) ohne Mehrfachkanten ▸ Knoten (V ), ▸ Kanten (E), ▸ einer Quelle q ∈ V , ▸ einer Senke s ∈ V und ▸ einer Kapazitätsfunktion c ∶ E → R+ , die jeder Kante (u, v) eine nicht-negative reelle Zahl c(u, v) als Kapazität zuordnet SoSe 2016 ⋅ M. Werner osg.informatik.tu-chemnitz.de Echtzeitsysteme – Scheduling Anhang B: Flußproblem 62 / 64 osg.informatik.tu-chemnitz.de Echtzeitsysteme – Scheduling Anhang B: Flußproblem Algorithmus von FORD und FULKERSON (Forts.) Algorithmus von FORD und FULKERSON (Forts.) Algorithmus 1. Initialisierung Beispiel (aus Wikipedia) ▸ ▸ u Für jeden e = (u, v) füge ein e = (v, u) ein Flussfunktion: ∀e′ , ϕ(e′ ) = 0 q 2 3 v u 4 Falls kein solcher P existiert á Ende q 3. Sei m = min(c(e)). Modifiziere N : 2 ▸ 6 1 4. Weiter mit 2. SoSe 2016 ⋅ M. Werner e′ ∈(s,vi ) ϕ(e′ ) 1 63 / 64 s 3 2 q osg.informatik.tu-chemnitz.de 3 1 1 3 3 s 3 1 s 3 SoSe 2016 ⋅ M. Werner q 1 4 1 3 q 3 1 3 3 v u 1 3 1 2 q 1 3 1 1 s 3 v u 1 2 v u 3 2 u 1 1 2 v u v u q ∑ 1 v ∀e = (u, v) ∈ P, c(e) ∶= c(e) − m ∀e = (u, v) ∈ P, ϕ(e′ ) = ϕ((v, u)) ∶= ϕ((v, u)) + m Maximaler Fluss: Φ = 1 3 e∈P ▸ s 6 2. Finde gerichteten Pfad P von q nach s mit ∀e ∈ P, c(e) > 0 ▸ 1 4 ′ s 4 q 1 4 1 3 u 1 2 v 64 / 64 s 3 s 4 4 q 2 3 1 1 v s 5 osg.informatik.tu-chemnitz.de