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
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
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
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
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
• 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”
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
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
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
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
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
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
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)
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
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
• 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
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.
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
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
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
• 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
• 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

Scheduling

Transcription

Documents pareils

Bewerbung für eine BWL

(RR) Round-Robin Scheduling

Fuhrparkmanagement und Controlling

Neubau Sporthalle Kepler- und Humboldt

Praktikum in der Online

Ein vernachlässigtes Areal wird gestaltet

HAFTUNG UND VERSICHERUNG HAVE RESPONSABILITÉ ET

Betriebssysteme I - Lehrstuhl "Betriebssysteme und verteilte Systeme"

Modehaus Honer investiert zwei Millionen Euro ins Stammhaus

2003 Echtzeitfaehige LAN

Betriebssysteme Prozessmanagement

IN8014 - Lehrstuhl für Angewandte Informatik

Betriebssysteme