Scheduling
Transcription
Scheduling
8. Scheduling (Ablaufplanung) 8.1.1 Scheduler- Überblick • regelt die Zuteilung der CPU, • wählt nächsten Thread aus der Bereit-Queue. • Anzahl der Threads & Prozesse ändert sich laufend. • Unterscheidung zw. Ablaufplanung mit und ohne Verdrängung: - Verdrängung (=Preemption) = Entzug d. CPU. - realisiert mit Hilfe von Zeitgeber-Interrupt. • Scheduler tritt in Aktion, wenn ein Thread: - startet & terminiert, freiwillig die CPU freigibt, auf eine E/A-Operation wartet, seine Zeitscheibe voll ausgenutzt hat. • Threadverhalten ändert sich dynamisch: - rechenintensive Phasen mit ununterbrochener CPU Nutzung und seltenen E/As. - E/A-lastige Zeitabschnitte mit nur kurzen CPU-Nutzungszeiten und häufigen E/As. 8-1 Betriebssysteme Sommer 2004, P. Schulthess, © VS Informatik Ulm 8.1.2 Scheduling-Ziele • Ziele teilweise gegenläufig, Overhead beim Umschalten der Tasks. • Antwortzeit: - Die Zeit zwischen einer Eingabe und der Übergabe der Antwortdaten an die Ausgabegeräte sollte minimal sein (Æ interaktive Systeme). • Effizienz: Optimale CPU-Ausnutzung. Bei Bedarf bis 100%. • Fairness: - Jeder Benutzer bzw. Prozess sollte im Mittel den gleichen CPU-Zeitanteil erhalten. • Ausführungszeit: - Die Zeitspanne vom Jobbeginn bis zum Jobende sollte sie minimal sein. - Sie enthält alle Zeiten in Warteschlangen, der Ausführung (Bedienzeit) und der E/A. • Durchsatz: - Zahl der Threads sollte möglichst gross sein (für Stapelsysteme wichtig wegen E/A) • Wartezeit: Wartezeit in der Bereit-Liste minimieren. 8-2 Betriebssysteme Sommer 2004, P. Schulthess, © VS Informatik Ulm 8.1.3 First Come First Served (FCFS) • Bearbeitung der Threads in Reihenfolge ihrer Ankunft in der Bereitliste. • Prozessorbesitz bis zum Ende oder freiwilligen Abgabe. T1 • Beispiel FCFS: - Günstiger Ablauf => - Ungünstiger Ablauf => • Nachteile: T2 T3 Ankunftszeiten und Laufzeiten T2 T3 T1 T1 Ankunftszeiten und Laufzeiten T2 T3 T1 T2 T3 - Konvoi-Effekt: schnelle Threads stauen sich hinter einem langsamen Thread. - E/A Nebenläufigkeit: CPU-lastige Threads halten I/O-lastige Threads auf. 8-3 Betriebssysteme Sommer 2004, P. Schulthess, © VS Informatik Ulm 8.1.4 Shortest Job First (SJF) • Bevorzugt kurze Threads. - Thread mit der kürzesten Zeitanforderung(Service time) als nächster bearbeitet. - Zeitanforderung muss bekannt sein, lang laufende Threads können verhungern. • Beispiel SJF: T1 T2 T3 Ankunftszeiten und Laufzeiten T4 • Mittlere Wartezeit: - preemptive: 3,5 T3 T2 T4 T1 preemptive Schedule - non-preemptive: 5,25 T1 T3 T2 T4 non-preemptive Sch. 8-4 Betriebssysteme Sommer 2004, P. Schulthess, © VS Informatik Ulm 8.1.5 Round Robin (Zeitscheibenverfahren) • Ziel: gleichmäßige Verteilung der CPU. • Beispiel: T1 T3 T2 Ankunftszeiten und Laufzeiten T4 • Richtige Wahl der Zeitscheibe: - Vernünftiges Verhältnis zwischen Quantum und Kontextwechselzeit notwendig. - Grosse Zeitscheiben sparen Kontextwechsel, verursachen aber lange Antwortzeiten. • Verbreitete Strategie (z.B. Linux und NT/XP): - Threads in Ankunftsreihenfolge verarbeiten. - Nach Ablauf einer vorher festgesetzten Frist (z.B. 20-50ms) findet Verdrängung statt. - Einreihung des Threads nach Ablauf der Zeitscheibe (Zeitquantums) am Ende der Bereit-Queue, sofern er nicht blockiert ist. 8-5 Betriebssysteme Sommer 2004, P. Schulthess, © VS Informatik Ulm 8.1.6 Prioritäts-Scheduling • Jeder Thread erhält eine Priorität. • Threads mit der höchsten Priorität wird aus der Bereit-Queue selektiert. • Implementierung: mehrere Bereits-Queues: - Vordergrund- und Hintergrundprozesse, - oder für jede Priorität eine Warteschlange. hohe Priorität TCBs niedrige Priorität 8-6 Betriebssysteme Sommer 2004, P. Schulthess, © VS Informatik Ulm • SJF ist prioritäts-basiertes Verfahren mit erwarteter Burst-Zeit als Priorität. • Aushungern (Starvation): - ein Thread mit niedriger Priorität bekommt die CPU nicht zugeteilt, da immer Threads mit höherer Priorität rechenbereit sind. - Lösung: Altern (Aging): Priorität steigt mit der Wartezeit Æ Feedback Scheduling. • Prioritätsinvertierung: - C „verhungert“ trotz höchster Priorität. - Thread B dominiert die CPU. - A kommt nicht zum Zuge und kann daher die Ressource nicht freigeben. - Thread C bleibt blockiert. - Altern als Lösung: Priorität von A steigt an. Sobald sie >8 ist, löst sich das Problem. - Bem.: War Problem bei Mars Pathfinder, siehe D. Wilner, „Vx-Files: What really happened on Mars?”, Keynote at the 18th IEEE Real-Time Systems Symposium, Dec. 1997. 8-7 Zustand “blockiert” wartet auf Thread C Prio=12 Ressource besitzt Thread A Prio=4 Thread B Prio=8 Zustand “bereit” Betriebssysteme Sommer 2004, P. Schulthess, © VS Informatik Ulm Zustand “rechnend” 8.1.7 Multilevel Scheduling • Kombination mehrerer Scheduling-Verfahren: - Bereit-Liste wird in Sublisten unterteilt. - Pro Subliste eigene Scheduling-Strategie. - Aufträge in passende Liste einsortieren. • Scheduling zwischen den Sublisten: - statische Priorität oder Zeitscheiben. • Beispiel: Prio 0: Systemprozesse Prio 1: Interaktive Jobs Prio 2: Allgemeine Jobs Prio 3: Rechenintensive Jobs 8-8 Betriebssysteme Sommer 2004, P. Schulthess, © VS Informatik Ulm 8.1.8 Feedback-Scheduling • Dynamische Anpassung der Scheduling-Kriterien - „Warte“-Historie eines bereiten Threads berücksichtigen, Zeitscheibenlänge, Priorität oder Einsortierung anpassen: Verhungern verhindern, Prioritätsinversion auflösen, Balance zw. E/A- u. rechenintensiven Threads. • Beispiel: Multilevel-Round-Robin - Threads, welche blockierende E/A-Fkt. aufrufen od. CPU freiwillig abgeben, bleiben in Warteschlange Æ E/A-lastige Threads bevorzugen. - Verdrängte Threads in Bereit-Liste Z 16ms mit längerer Zeitscheibe einordnen e (benötigen mehr Zeit), i 32ms t - Aging. s c h e i b e 8-9 hohe Priorität TCBs 64ms 128ms niedrige Priorität 256ms Betriebssysteme Sommer 2004, P. Schulthess, © VS Informatik Ulm 8.1.9 Strategien für Echtzeitsysteme • Echtzeitsysteme müssen def. Zeitschranken einhalten, auch in Fehlersituationen. • Für krit. Anwendungen (z.B. Kernkraftwerk). • Threads erhalten Sollzeitpunkte (Deadlines). - Voraussetzung: Laufzeit vorab bekannt. - Harter Echtzeit: Verletzung bedeutet Ausfall des Systems (nicht tolerierbar). - Weicher EZ: Qualitätseinbußen bei Verletzung, aber in Grenzen tolerierbar. • Keine Desktop-OS, sondern eingebettete Systeme (z.B. OSEK). Offline-Scheduling • Vorberechnung eines vollständigen Ausführungsplans in Tabellenform. • Pre-Scheduling zur Vermeidung von Scheduling-Overhead. • Einfacher Tabellenzugriff während der Ausführung. • Sinnvoll für harte Echtzeitanforderung. 8-10 Betriebssysteme Sommer 2004, P. Schulthess, © VS Informatik Ulm Earliest Deadline First (EDF) • Thread mit engster Frist wird bevorzugt. - Verbreitete Strategie. - Threads mit Ausführungsfristen. • Beispiel: Earliest Deadline First - Laufzeit: t(T1)=4, t(T2)=5, t(T3)=3 - Fristen: f(T1)=10, f(T2)=7, f(T3)=17 - non-preemptive; gleiche Ankunftszeit. T2 T1 0 - preemptive: Ankunftszeiten: at(T1)=0, at(T2)=1, at(T3)=2. 5 T1 0 T3 1 9 T1 T2 6 9 • Dynamisch Einplanen, wenn neuer Thread hinzukommt. • CPU Auslastungsgrenze bis zu 100%. 8-11 Betriebssysteme Sommer 2004, P. Schulthess, © VS Informatik Ulm 12 T3 11 Rate Monotonic Scheduling (RMS) • Zur Beschreibung periodischer Systeme (z.B. Multimediaströme): - hohe Priorität für Tasks mit hoher Frequenz, niedrige Prio. für seltenere Tasks. - Ende der Periode entspricht der Deadline. • Bewertung: - CPU Auslastungsgrenze nur bis ~70%. Voraussetzung: Threads sind unabhängig voneinander. Minimale Verzögerung für häufig wiederholte Tasks, Zerstückelung niederfreq. Tasks. Situationen, die durch Verzögerung eines höher priorisierten Threads, zu einem gültigen Ablauf führen, sind nicht lösbar. • Beispiel: - Laufzeit: t(T1)=3, t(T2)=2, t(T3)=1, t(T4)=1, t(T5)=2. - Periode: p(T1)=13, p(T2)=15, p(T3)=9, p(T4)=16, p(T5)=10. T1 T2 T3 T4 T5 8-12 Zeit Betriebssysteme Sommer 2004, P. Schulthess, © VS Informatik Ulm 8.1.10 Mehrprozessor-Aspekte • Lastausgleich zwischen CPUs durch den Scheduler. • Prozessor-Affinität: TCB wird erweitert um zuletzt benutzte CPU. • Wahllose CPU-Zuteilung schlecht: - Hat Thread t zuletzt Prozessor p genutzt, so besteht die Chance, dass noch Teile seines Adressraums im Cache von p vorhanden sind. • Nachteil: Aufweichung von Prioritäten: - Eventuell ist die zuletzt genutzte CPU belegt und eine andere gerade frei, - falls auf alte CPU gewartet wird, so läuft evt. ein Thread mit niedriger Priorität zuerst. 8.1.11 Leerlauf-Prozess (Idle-Task) • Falls alle Threads warten ist die CPU frei und es läuft ein Leerlauf-Thread: - darf nicht anhalten, hat geringste Priorität, muss jederzeit verdrängbar sein. • Leerlauf nutzbar für: - Prüfungen, Garbage Collection, Heap Kompaktifizierung, Strom sparen. 8-13 Betriebssysteme Sommer 2004, P. Schulthess, © VS Informatik Ulm 8.1.12 Scheduling in Unix System VR3: • Scheduler kennt nur Prozesse, keine Threads. • Verdrängendes Feedback-Scheduling (preemptive): - z.B. pro Priorität eine Queue mit Round Robin. - Scheduler setzt Prioritäten von Benutzerprozessen (beginnen z.B. mit n/2) dynamisch. - Benutzer beeinflusst Priorität mit setpriority bzw. nice, aber es gilt PrioUser > PrioSystem. - Hier gilt, je kleiner der Wert desto besser die Priorität. • Kern ist nicht verdrängbar: Ein Prozess der im KernelModus läuft kann erst beim Rücksprung in den UserModus verdrängt werden. 8-14 -m … Systemprozesse (statische Priorität) -1 0 … n Benutzerprozesse (dynamische Priorität) Betriebssysteme Sommer 2004, P. Schulthess, © VS Informatik Ulm Dynamische Anpassung von Prioritäten: - Jede Sekunde für die Prozesse in der Bereit-Queue die Priorität berechnen. Formel: dyn_prio:=base_prio + cpu_usage / 2 + nice (CPU-Nutzung in „Uhr-Ticks”). Prozessornutzung wird schrittweise „vergessen”: cpu_usage := cpu_usage / 2. zusätzlich wird alle 40ms dyn_prio des laufenden Prozesses neu berechnet. • Starke CPU-Nutzung führt zu schlechter Prio.: - rechenintensive Proz. werden benachteiligt und I/O-intensive Proz. werden bevorzugt. - Æ I/O-lastige Proz. belegen die CPU nur kurz, um einen E/A-Auftrag abzusetzen. - Man erreicht dadurch eine Balance zw. CPU- und I/O-lastigen Aufgaben. • Blockiert Proz., weil er auf ein Ereignis wartet: - so erhält er abh. vom Ereignis eine höhere Kernel-Priorität. - Beim Übergang v. Kernel- in den User-Mode erhält er wieder seine alte User-Prio. • Die Prioritäten, die Benutzer sieht, werden oft auf andere Werte im Kern abgebildet. 8-15 Betriebssysteme Sommer 2004, P. Schulthess, © VS Informatik Ulm 8.1.13 Scheduling in BSD Unix 4.3 • 32 Queues (Einordnung Priorität/4): - System-Proz.: 0-49; Benutzer-Proz.: 50-127. - jeweils mit einer Zeitscheibe von 100ms. • Anpassen von Prioritäten: - p_cpu = geschätzte CPU-Nutzung. (wird für lfd. Proz. alle 10ms inkrementiert). - p_nice = Gewichtungsfaktor vom Benutzer definiert (-20 bis +20). - PUSER = statische Priorität des Proz. - nach 4 Ticks (40ms) Update für lfd. Proz.: p_usr = PUSER + [p_cpu / 4] + 2*p_nice - Damit Prioritäten nicht ständig wachsen, für bereite Proz. jede Sek. anpassen: p_cpu = (2*load)/(2*load+1) * p_cpu + p_nice • load = Abschätzung d. CPU-Auslastung. - Durchschnitt der Summe der Zeitquanten aller P. in der Bereit-Q der letzten Minute. • Anpassung leider nur für rechenbereite Prozesse. 8-16 Betriebssysteme Sommer 2004, P. Schulthess, © VS Informatik Ulm • Dynamische Prioritäten für wartende Proz.: - Neuberechnung der Priorität wartender Prozesse. - Basis: p_slptime = Wartezeit des Prozesses in Sekunden - Beim Aufwecken des Prozesses: p_cpu = ( (2*load)/(2*load+1) ) p_slptime * p_cpu 8-17 Betriebssysteme Sommer 2004, P. Schulthess, © VS Informatik Ulm 8.1.14 Multi-level Scheduling in Linux • Alle lauffähigen Prozesse in einer drei Bereit-Queues gespeichert. • Prozesse & Threads werden als Tasks verwaltet. • Kernel ist nicht verdrängbar. • Ebene 1: SCHED_FIFO (First-in-first-out): - für Echtzeitprozesse. Queue nur für root zugänglich. statische Prioritäten von 1 bis 99. verwendet FCFS innerhalb einer Prioritätsstufe. Verdrängung durch Proz. mit höherer statischer Priorität (sonst unlimitierte CPU-Zeit). • Ebene 2: SCHED_RR: - wie SCHED_FIFO, aber Round Robin für jede Prioritätsstufe. • Klasse 3: SCHED_OTHER (Multilevel Feedback): 8-18 für normale Prozesse. statische Priorität: -20 bis + 20 (zu Beginn 0). Gewichtung mit nice & setpriority (-19 bis +20). zusätzlich dynamische Anpassung v. Prioritäten. Betriebssysteme Sommer 2004, P. Schulthess, © VS Informatik Ulm Epochen und Prioritäten: • Linux verwendet keine fortlaufende Zeit, sondern Epochen. - In einer Epoche hat jeder P. ein best. Zeitquantum für die CPU-Nutzung zur Verfügung. Dieses wird zu Beginn der Epoche berechnet. Proz. kann CPU pro Epoche mehrfach erhalten, sofern Zeitquantum nicht verbraucht ist. Epoche endet, wenn alle Prozesse in Bereit-Queue ihr Zeitquantum verbraucht haben. Blockierte Proz. werden hierbei nicht beachtet! • Zeitquantum entspricht Priorität. • Berechnung des Zeitquantums (ZQ): - Wenn Prozess in Bereit-Queue eingefügt wird und zu Beginn einer neuen Epoche. Basis sind 200ms (20 clocks ticks). falls Zeitquantum (ZQ) verbraucht: Basis zuteilen, sonst: Basis + ZQalt/2. I/O-lastige Proz. verbrauchen ihre Zeitscheibe nicht und erhalten dafür einen Bonus. • Prioritäten im Prozesskontrollblock: - rt_priority: statische Prio. von Echtzeitproz. - priority: Basis-Zeitquantum (inkl. nice-Gew.). - counter: Anzahl verbleibender CPU-Ticks im Zeitquantum in der akt. Epoche. 8-19 Betriebssysteme Sommer 2004, P. Schulthess, © VS Informatik Ulm Prozessbewertung über "goodness"-Funktion: • Scheduler selektiert Proz. aus Bereit-Queue mit Hilfe goodness-Funktion. • Rückgabewert der goodness-Funktion: -1: 0: 1-999: >=1000: Proz. hat CPU freiwillig abgegeben. Proz. hat Quantum voll ausgenutzt. normaler Proz. mit noch (teilweise) unverbrauchtem Quantum. Echtzeitprozess. • Berechnung bei normalen Prozessen: if (p->policy != SCHED_OTHER) return 1000 + p->rt_priority; if (p->counter == 0) return 0; // Echtzeitpriorität // Quantum verbraucht? if (p->mm == prev->mm) // gleicher Adr.raum? return p->counter + p->priority + 1; return p->counter + p->priority; 8-20 Betriebssysteme Sommer 2004, P. Schulthess, © VS Informatik Ulm 8.1.15 Scheduling in Windows NT • Scheduler betrachtet ausschließlich Threads. • Verdrängendes, auf Zeitscheiben basierendes Scheduling mit Prioritäten: - Workstation-Zeitsch.: 20-30 ms. - Server-Zeitscheibe: 150-180 ms. 32 Prioritätsklassen: höchste (31) - 32 FiFo-Queues, - Leerlaufthread: 0. - variable Priorität: 1-15. - Echtzeitpriorität 16-31 (statisch). Echtzeitpriorität … geringste (16) höchste (15) … variable Priorität geringste (0) 8-21 Betriebssysteme Sommer 2004, P. Schulthess, © VS Informatik Ulm • Präemptiver Kern - User-Threads können auch Kernel-Threads verdrängen. • Prioritäten berechnen sich aus der Prozessklasse und dem relativen Thread-Prioritätslevel. • Prozessklassen (PKL): - IDLE: NORMAL: HIGH: REALTIME: Priorität 4 Priorität 8 Priorität 13 Priorität 24 • Thread-Prioritätslevel: - IDLE: Priorität 1 bzw. 16 LOWEST: Priorität = PKL – 2 BELOW_NORMAL: Priorität = PKL – 1 NORMAL: Priorität = PKL ABOVE_NORMAL: Priorität = PKL + 1 HIGHEST: Priorität = PKL + 2 TIME_CRITICAL: Priorität 15 bzw. 31 • Prioritätsklasse ü. Taskmgr. anpassen. 8-22 Betriebssysteme Sommer 2004, P. Schulthess, © VS Informatik Ulm • Richtige Echtzeitfähigkeiten (Deadlines) nicht vorhanden, sondern nur höhere Prioritäten. • Prioritätserhöhung für GUI-Threads: - Die mit einem Fenster arbeiten u. auf Benutzereingaben oder Fensternachrichten warten. - Auf Priorität 14 & Verdopplung der Zeitscheibe. • Prioritätserhöhung nach Blockierung: - Wenn E/A-Auftrag beendet ist, auf den ein Thread gewartet hat, so wird dessen Priorität erhöht (1-8 Level) = Priority Boost. - Nach einem Priority-Boost, wird nach jedem Ablauf einer Zeitscheibe, die Priorität wieder um 1 erniedrigt, bis zum Ausgangswert. • Verhungern / Prioritätsinversion: - Rechenbereite Threads, die seit mind. 3 Sek. auf den Prozessor warten. - Priorität auf 15 und Quantum verdoppeln. - Sobald CPU abgegeben bzw. entzogen wird, Werte wieder zurücksetzen. 8-23 Betriebssysteme Sommer 2004, P. Schulthess, © VS Informatik Ulm