Prof. Dr. Peter Mandl Seite 1
CPU-Scheduling - Fallbeispiele
Sommersemester 2015
Prof. Dr. Peter Mandl
Prof. Dr. Peter Mandl Seite 2
Gesamtüberblick
10
Job A
Job B
16 20 30
Job C
Job D
Job E
22 Verweilzeit
Alle Aufträge
beginnen hier
6
Job A
Job B
14 24 30
Job C
Job D
Job E
28 Verweilzeit
Alle Aufträge
beginnen hier
1. Einführung in Computersysteme
2. Entwicklung von Betriebssystemen
3. Architekturansätze
4. Interruptverarbeitung in Betriebssystemen
5. Prozesse und Threads
6. CPU-Scheduling
7. Synchronisation und Kommunikation
8. Speicherverwaltung
9. Geräte- und Dateiverwaltung
10.Betriebssystemvirtualisierung
Prof. Dr. Peter Mandl Seite 3
Überblick
1. Fallbeispiel: Unix
2. Fallbeispiel: Linux
3. Fallbeispiel: Windows
4. Fallbeispiel: Scheduling in Java
Prof. Dr. Peter Mandl Seite 4
Scheduling-Strategien unter Unix
Jedes Unix-Derivat hat Feinheiten in der Scheduling-Strategie
Es gibt aber prinzipielle Gemeinsamkeiten
Unterstützte Scheduling-Strategie:
- Preemptives Verfahren (Linux auch non-preemptive)
- Prozess als Scheduling-Einheit in traditionellem Unix
- RR mit Prioritäten und Multi-Level-Feedback-Scheduling
• Eine Queue je Priorität
• Round Robin innerhalb der gleichen Priorität
• Vorderster Prozess aus aktuell höchster Priority-Queue wird als nächstes ausgewählt
• Nach Ablauf der Zeitscheibe wird der Prozess ans Ende seiner aktuellen Queue oder ans Ende einer anderen Queue gehängt
Prof. Dr. Peter Mandl Seite 5
Run-Queue unter Unix
Multi-Level-Feedback-Warteschlangen organisiert in der sog. Run-Queue
Run queue
PCB-Tabelle
Verkettete PCB-Liste für jede Priorität 255
...
178
177
...
129
128
127
...
0
... Realtime
System
User
Prio
...
...
PCB 1
PCB 2
PCB 3
PCB 4
PCB 5
PCB 6
...
Prof. Dr. Peter Mandl
Scheduling unter Unix: Prioritätsberechnung
Jeder Prozess erhält eine initiale Priorität beim Start, die sich mit der Zeit verbessert
Priorität in früheren Unix-Systemen: -127 (höchste) bis +127
Priorität in heutigen Unix-Systemen: z.B. von 0 (höchste) bis 255
Die Priorität wird zyklisch, z.B. jede Sekunde, neu berechnet (System V)
Als Parameter geht die CPU-Nutzung der Vergangenheit in die Berechnung ein
- War diese in der letzten Zeit hoch, wird die Priorität niedriger
- I/O-intensive Prozesse (Dialogprozesse) werden bevorzugt
Seite 6
Prof. Dr. Peter Mandl Seite 7
Einschub: nice-Befehl unter Unix
nice-Befehl beeinflusst die statische Priorität beim Starten eines Programms: Nett zu anderen Prozessen sein, da die eigene Priorität meist
herabgesetzt wird
Nice-Prioritätenskala: von 20 bis -19 (höchste) Je größer der nice-Wert, desto niedriger die Priorität
Nutzung: nice -<nicewert> <command> - Programm <command> wird mit einer um <nicewert> niedrigeren
Priorität als der Standardwert gestartet
Vorsicht: Syntax je nach Shell etwas anders!
Test: nice -10 bash
Nur der User mit root-Berechtogung darf die Priorität erhöhen
Andere Befehle/Systemcalls - renice: Dient zum Verändern der Priorität eines laufenden Prozesses
- setpriority: Neuer Befehl anstelle von nice
Prof. Dr. Peter Mandl Seite 8
Überblick
1. Fallbeispiel: Unix
2. Fallbeispiel: Linux
3. Fallbeispiel: Windows
4. Fallbeispiel: Scheduling in Java
Prof. Dr. Peter Mandl Seite 9
Scheduling-Strategien unter Linux: O(1)-Scheduler (bis Kernel-Version 2.6.22)
RR mit Prioritäten und Multi-Level-Feedback-Mechanismus
Scheduling-Einheit ist der Thread (Implementierung auf Kernelebene) Thread und Prozess sind identisch!
Unterstützte Scheduling-Strategien: „ps -c“ zeigt Strategien der Threads/Prozesse an!
- Realtime FIFO (POSIX) SCHED_FIFO
• Höchste Priorität und non-preemptive (!)
- Realtime Round Robin (POSIX) SCHED_RR
• Wie FIFO aber preemptive, Nutzung einer Zeitscheibe
- Timesharing
• Standard-Threads
• SCHED_BATCH, SCHED_OTHER und SCHED_IDLE
Anm: Keine echten Realtime-Threads, sondern P.1003.4-Konformität (Unix real-time extension)
Prof. Dr. Peter Mandl Seite 10
O(1)-Scheduler: Run-Queue unter Linux (1)
Multi-Level-Feedback-Warteschlangen werden auch unter Linux über eine „Run-Queue“ verwaltet
Run-Queue
PCB 1
PCB-Tabelle
PCB 2
PCB 3
PCB 4
PCB 5
PCB 6
...
...
...
...
...
Prio
Verkettete PCB-Liste für jede
Priorität
0
...
99
100
...
...139
Realtime
Timesharing
Hinweis zum O(1)-Scheduler: Bezeichnung deshalb,
weil die Laufzeit für die Auswahl des nächsten Prozesses unabhängig von aktueller Prozessanzahl ist
Prof. Dr. Peter Mandl Seite 11
O(1)-Scheduler: Run-Queue unter Linux (2)
Prozess 200
Detailinformationen zu den
Prozessen/Threads in
task_struct-Datenstrukturen
(PCBs)
Prozess 232
...
...
Bitmap
Verkettete Prozess-Liste für
jede Priorität
0...
99
100...
139
Realtime-
Prio-Liste
Timesharing-
Prio-Liste
Active-Queuenr_active
Prozess 434
Prozess 699...
...
BitmapPrio
0...
99
100...
139
Expired-Queuenr_active
nr_running
Active-Zeiger
Expired-Zeiger
Current-Zeiger
Run-QueueIdle-Zeiger
dito wie Active-Queue
Idle-Prozess
...
...
... ...
Struktur prio_array
Struktur runqueue
Active Queue und expired Queue
Prof. Dr. Peter Mandl Seite 12
O(1)-Scheduler: Loadbalancer unter Linux
Je Prozessor gibt es eine Run-Queue
Loadbalancer verteilt die Arbeit
Loadbalancer
Prozess
Prozess
active
Prozess
Prozess
expired
Run-Queue CPU 1
CPU 1
Prozess
Prozess
active
Prozess
expired
Run-Queue CPU 2
CPU 2
.... Prozess
Prozess
active expired
Run-Queue CPU n
CPU n
Prof. Dr. Peter Mandl Seite 13
O(1)-Scheduler: Arbeitsweise des Linux-Schedulers
Die CPU wird einem Thread entzogen, wenn
- die Zeitscheibe (Quantum) abgelaufen ist
- der Thread blockiert (Warten auf Ressource)
- ein Thread mit höherer Priorität wird „ready“
• D.h.: Zwischendurch muss dies geprüft werden
• nach jedem Tick bei der Systemclock-Interrupt-Bearbeitung!
Die Quanten der Prozesse der höchsten Priorität werden soweit möglich abgearbeitet (außer wenn Prozess blockiert ist), danach wird die nächst niedrige Prioritäts-Queue bearbeitet
- Echtzeitprozesse können die anderen behindern
Prof. Dr. Peter Mandl Seite 14
Einschub: Skizze einer Timer-Interrupt-Routine
timer_interrupt() // Interrupt Service Routine für Systemuhr
{
Systemuhr anpassen;
Statistiken in Kerneldatenstrukturen aktualisieren;
Quantumszähler aktiver Prozesse reduzieren;
if (Prozess mit höherer Priorität im Zustand „ready“) {
schedule(); // Dispatcher aufrufen
}
else if (Quantum des laufenden Threads == 0) {
schedule(); // Dispatcher aufrufen
}
…
}
Prof. Dr. Peter Mandl Seite 15
Linux-Prioritäten
Jedem Thread wird eine statische und eine dynamische (effektive) Priorität zugeordnet
- Prioritätenskala intern: 0 bis 139
- Timesharing-Prioritäten liegen im Bereich von 100 bis 139 (100 ist höchste)
• Standardwert = 120
• nice-/setpriority-Systemdienst ermöglicht eine Veränderung der statischen Priorität zwischen -20 und +19 (wie unter Unix)
- Priorität 0 bis 99 sind Echtzeitprioritäten
Höhere Priorität mehr CPU-Zeit (höheres Quantum)
für den Prozess
Veränderung der effektiven Priorität führt zum Einhängen des Prozesses in andere Queue
Prof. Dr. Peter Mandl
O(1)-Scheduler: Quantumsberechnung unter Linux
Timesharing: Quantumsberechnung auf Basis der statischen Priorität in [ms]
quantum = f(static_prio) = (140 – static_prio) * 20, falls static_prio < 120
quantum = f(static_prio) = (140 – static_prio) * 5, falls static_prio >= 120
Beispiel: f(100) = (140 - 100) * 20 = 800 [ms]
100
800
120 139 Statische Priorität
(static_prio)
Quantum
in ms
100 105 110 115 125 130
700
500
400
300
200
600Höchste
Prio.
Die Quantumsberechnung z.B. in Timer-Interrupt-Routine
Seite 16
Prof. Dr. Peter Mandl
O(1)-Scheduler: Bonuszuteilung unter Linux
Bonus für Priorität in Abhängigkeit der durchschnittlichen Schlafzeit
- Negativer Bonus Verbesserung der Priorität
- Prio-Veränderung Einordnen in andere Queue
Effektive Priorität ~ (Statische Priorität + Bonus)
5
0
-5
500 1000 Durchschn.
Schlafzeit in [ms]
Bonus I/O-intensiver Prozess Guter
Bonus
Seite 17
Prof. Dr. Peter Mandl Seite 18
O(1)-Scheduler: Zusammenfassung
Statische Prioritäten bestimmen die CPU-Zuteilung und die Quantumszuteilung
Die effektive Priorität bestimmt die Einordnung in der Run-Queue
Rechenintensive Threads verbrauchen ihr Quantum schnell und erhalten dann ein Quantum abhängig von ihrer statischen Priorität und einen positiven Bonus (schlecht!) auf die effektive Priorität
also beeinflusst die statische Priorität das Quantum und die Rechenintensität die Priorität
Durchschnittliche Schlafzeit beeinflusst die Entscheidung, ob ein Prozess interaktiv (I/O-intensiv) oder rechenintensiv ist
I/O-intensive Threads erhalten einen negativen (gut!) Bonus auf die effektive Priorität und werden damit früher zugeteilt
Bonuszuteilung für müde Prozesse höhere Priorität
Prof. Dr. Peter Mandl Seite 19
Completely Fair Scheduler CFS: Überblick
Löst O(1)-Scheduler ab Linux-Version 2.6.23 ab
Scheduler für Timesharing-Prozesse
Modul fair.c, ca. 4.400 SLOC, implementiert CFS
Modul rt.c: nur noch ca. 1700 SLOC, implementiert nur noch Realtime-Scheduling mit nur noch 100 Prioritäten
Besonderheiten:
Keine Statistiken, keine Run Queue und kein Switching von active nach expired Queue
keine Quanten (Zeitscheiben)
Hinweis: CFS ist umstritten, da evtl. Nachteile für Workstations, aber Vorteile für Server
Prof. Dr. Peter Mandl
Completely Fair Scheduler CFS: Strategie
Einfache Strategie:
- Für jeden Prozess/Thread wird ein vruntime-Wert (Nanosekunden-Basis) verwaltet
- vruntime enthält die Entfernung von der idealen CPU-Nutzung
- Beispiel: 5 Prozesse 20 % CPU je Prozess
- Prozess mit niedrigster vruntime wird als nächstes gewählt und bleibt so lange aktiv, bis wieder ein fairer Zustand erreicht wurde
- Ziel: Wert von vruntime für alle Prozesse gleich halten
Hinweis:
- Linux-Kommando chrt -p <pid> liefert Scheduling-Policy und Priorität eines Prozesses und man kann mit chrt auch die Scheduling-Policy eines Prozesses setzen
Seite 20
Prof. Dr. Peter Mandl Seite 21
Überblick
1. Fallbeispiel: Unix
2. Fallbeispiel: Linux
3. Fallbeispiel: Windows
4. Fallbeispiel: Scheduling in Java
Prof. Dr. Peter Mandl
Scheduling-Strategien unter Windows
Windows verwendet ein
- prioritätsgesteuertes,
- preemptives Scheduling
- mit Multi-Level-Feedback
Threads dienen als Scheduling-Einheit
Seite 22
Prof. Dr. Peter Mandl
Prioritäten unter Windows: Kernelprioritäten
Threads werden nach Prioritäten in Multi-Level-Feedback-Warteschlangen organisiert
Interne Kernelprioritäten 0 (niedrigste) bis 31
- Nullseiten- und Idle-Thread haben die Priorität 0 (siehe Speicherverwaltung)
- Prioritäten 16 – 31 (Echtzeit) verändern sich nicht
- Prioritäten 1 – 15 sind dynamisch (Benutzerprozesse)
16
Echtzeitebenen
31
15
15 variable
Ebenen
16
1
0 1 Systemebene
Seite 23
Prof. Dr. Peter Mandl Seite 24
Run-Queue unter Windows
Multi-Level-Feedback-Warteschlangen
Ready-Queue für
Prozessor 1
...
...
...
Prio
Verkettete TCB-Listen für jede Priorität31...
16
15...
1
0
Realtime und
Systemprioritäten
Variable Prioritäten,
Userpriorität
System
Deferred Ready Queue
10000000……….00000010
Ready Summary (Bit-Map)
031 Threads im Zustand
Deferred Ready für jeden
Prozessor
...
...
Ready-Queue für
Prozessor 2
...
...
...
Deferred Ready Queue
00000000……….0000001
Ready Summary
031
31...
16
15...
1
0
Deferred Ready: Threads, die schon einem Prozessor zugeordnet sind, aber noch nicht aktiv sind
Prof. Dr. Peter Mandl Seite 25
Prioritäten unter Windows: WinAPI-Prioritäten
Es gibt 6 WinAPI-Prioritätsklassen der Prozesse (Basisprioritäten)
- Werte sind: idle, below normal, normal, above normal, high und real-time
... und (relative) Threadprioritäten
- Werte sind: time critical, highest, above normal, normal, below normal, lowest, idle
Aufruf von SetPriorityClass()
- bewirkt die Veränderung der Prioritätsklasse für alle Threads eines Prozesses
Aufruf von SetThreadPriority() - Threadpriorität kann aktiv verändert werden
- Nur innerhalb eines Prozesses
Prof. Dr. Peter Mandl Seite 26
Prioritäten unter Windows: Mapping
WinAPI-Prioritäten werden auf die interne Kernelprioritäten abgebildet
Hinweis: Prioritätsklasse eines Prozesses kann mit dem Taskmanager verändert werden
Testen: Testen Sie das Kommando „start /high notepad“
Prioritätsklasse
Windows-Thread-Priorität
real-time high above normal
normal
time critical 31 15 15 15
highest 26 15 12 10
above normal 25 14 11 9
normal 24 13 10 8
below normal 23 12 9 7
lowest 22 11 8 6
idle 16 1 1 1
...
Prof. Dr. Peter Mandl Seite 27
Prioritäten unter Windows: Vererbung
Ändert man die Priorität eines Prozesses, werden die Prioritäten der Threads ebenfalls geändert
System-Prozesse nutzen speziellen Systemcall NTSetInformationProcess
Taskmanager zeigt nur Basispriorität
Prozess 1
Thread 1
Prozess 1erzeugtProzess 2
Prozess 2 erbt Basispriorität von Prozess 1
Prozess 2 erzeugt Thread 1
Thread 1 erbt relative Basispriorität von Prozess 2
Thread hat auch eine dynamische Priorität (wird für das Scheduling genutzt)
SetPriorityClass()
SetThreadPriority()
Prozess hat nur eine Priorität
verändert Basispriorität des Threads
Verändert Prioritätsklasse des Prozesses und seiner Threads
Prozess 2
Prof. Dr. Peter Mandl Seite 28
Clock-Intervall und Quantum
Clock-Intervall
- ca. 10 ms bei x86 Singleprozessoren
- ca. 15 ms bei x86 Multiprozessoren
- siehe clockres-Tool zum Feststellen des Clock-Intervalls
Quantum
- Quantumszähler je Thread
• Auf 6 bei Workstations (Windows 2000, XP, ...) eingestellt
• Auf 36 bei Windows-Servern eingestellt
• Quantumszähler wird je Clock-Interrupt um 3 reduziert
Quantumsdauer = 2 (Workstation) bzw. 12 (Server) Clock-Intervalle
• 2 * 15 ms = 30 ms bei x86-Workstations
• 12 * 15 ms = 180 ms bei Servern
Prof. Dr. Peter Mandl Seite 29
Arbeitsweise des Schedulers: Szenario 1
Szenario: Priority Boost (Prioritätsanhebung) für Threads nach einer Ein-/Ausgabe-Operation
- Anhebung max. auf Priorität 15
- Treiber entscheidet
• Maus-/Tastatureingabe: +6
• Ende einer Festplatten-I/O: +1
x
Zeit
Priorität
Basis-
priorität
Zeitquantum
Thread aktiv
Thread wartet auf
Ein-/Ausgabe
...
Anhebung
der Priorität
X <= 15
Basispriorität
wieder erreicht
Verdrängung durch höher
priorisierte Threads jederzeit
möglich
Prof. Dr. Peter Mandl
Arbeitsweise des Schedulers: Szenario 2
Szenario: Rettung verhungernder Threads
Threads mit niedrigerer Priorität könnten benachteiligt werden
- Rechenintensive Threads höherer Priorität kommen immer vorher dran
Daher: Jede Sekunde wird geprüft, ob ein Thread schon länger nicht mehr dran war, obwohl er bereit ist
- Ca. 4 Sekunden nicht mehr dran?
- Wenn ja, wird er auf Prio. 15 gehoben und sein Quantum wird vervierfacht (ab Windows 2003) Prüfen
Danach wird er wieder auf den alten Zustand gesetzt
Also: Ein Verhungern wird vermieden!
Seite 30
Prof. Dr. Peter Mandl Seite 31
Arbeitsweise des Schedulers: Szenario 3
Szenario: Rettung verhungernder Threads
15
Zeit
Priorität
Basis-
priorität
Thread aktiv bei erhöhten
Quantum
Thread aktiv
Thread wartet auf
Ein-/Ausgabe
Thread wartet
auf Zuteilung
...
Anhebung der
Priorität
Windows 2000/XP: Verdoppelung
Windows 2003: Vervierfachung
Prof. Dr. Peter Mandl Seite 32
Einschub: Vergleich Linux - Windows
Kriterium Windows Linux O(1)-Scheduler
Unterstützte Prozesstypen
Timesharing- und Echtzeitprozesse; Unterscheidung über Priorität
Timesharing, Realtime mit FIFO, Realtime mit RR; Unterscheidung über Priorität
Prioritätsstufen Interne Kernelprioritätsstufen von 0 – 31: 0 – 15: Timesharing-Threads 16 – 31: Realtime- und System-Threads Eigene WinAPI-Prioritäten mit Basisprioritäten für Prozesse und Relativprioritäten für Threads
Statische und effektive Prioritäten mit Stufen von 0 – 139 (139 niedrigste): 0 – 99: Realtime-Prozesse 100 – 139: Timesharing-Prozesse
Scheduling-Strategie für Timeharing-Prozesse
Thread-basiert, Begünstigung von interaktiven vor rechenintensiven Threads Quanten, prioritätsgesteuert, Round Robin, Multi-Level-Feedback-Queue, 32 Queues
Prozess-basiert, Begünstigung von interaktiven vor rechenintensiven Prozessen (Thread = Prozess) Quanten, prioritätsgesteuert, Round Robin, Multi-Level-Feedback-Queue, 140 Queues
Prioritätenberechnung für Timesharing-Prozesse
Aktuelle Prioriät wird zur Laufzeit berechnet, Priority-Boost bei wartenden Threads nach Wartezeit oder bei GUI-Threads
Effektive Priorität wird zur Laufzeit berechnet, abhängig von statischer Priorität und einem Bonus (+/- 5) für lang schlafende Prozesse; Effektive Prio = statische Prio + Bonus (vereinfacht)
Quantumsberechnung für Timesharing-Prozesse
Quantumszähler = 6 bei Workstations und 36 bei Windows Servern, bei jedem Clock-Intervall wird Zähler um 3 dekrementiert; Clock-Intervall ist ca. 10 ms bei x86-Singleprozessoren (100 Hz) und ca. 15 ms (67 Hz) bei Multiprozessoren Quantumserhöhung bei GUI-Threads oder zum Vorbeugen vor Thread-Verhungern
Abhängig von statischer Priorität Quantum = (140 - statische Prio) * 20 [ms] (oder * 5) Maximum 800 ms Takt der internen Systemuhr von Linux bis Linux 2.5 auf 100 Hz einstellbar, ab Linux 2.6 auf 100, 250, 300, 1000 Hz; bei jedem Tick wird das Quantum der aktiven Prozesse um das Clock-Intervall reduziert
Prof. Dr. Peter Mandl
Einschub: Echtzeit- versus Universalbetriebssysteme
Echtzeitbetriebssystem: Embedded Linux, …
Universal-Betriebssystem: Windows, Linux, Unix, Mainframes, ...
Unterstützt harte Echtzeitanforderungen (Garantien, Deadlines)
Unterstützt nur “weiche” Echtzeitanforderungen (keine Garantien, keine Deadlines)
Ist auf den Worst-Case hin optimiert Optimierung auf die Unterstützung verschiedenster Anwendungsfälle hin, Reaktionszeit nicht im Vordergrund
Vorhersagbarkeit hat hohe Priorität bei der Auswahl des nächsten Tasks
Effizientes Scheduling mit fairem Bedienen von allen Prozessen, insbesondere von Dialogprozessen steht meist im Vordergrund
Meist werden wenige dedizierte Funktionen unterstützt
Viele Anwendungen können auf einem System laufen
Zeitoptimierung wichtig Durchsatz und Antwortzeitverhalten wichtig
Universalbetriebssysteme implementieren Mechanismen, die deterministische Umschaltungen erschweren:
Schedulingstrategien, Paging, Kernelmodus, Interruptbearbeitung, vorgegebene Zeitgranularitäten,…
Seite 33
Prof. Dr. Peter Mandl Seite 34
Überblick
1. Fallbeispiel: Unix
2. Fallbeispiel: Linux
3. Fallbeispiel: Windows
4. Fallbeispiel: Scheduling in Java
Prof. Dr. Peter Mandl
Scheduling in Java: Prioritäten
Scheduling auf Basis von Priorität und Zeitscheibe
Jeder Thread hat eine Priorität
Mögliche Prioritäten und deren Manipulation:
- siehe Attribut Thread.Max.Priority
- MIN, NORM, MAX
- setPriority()
- getPriority()
Thread mit hoher Priorität wird bevorzugt
Aber: Tatsächliche Priorisierung hängt von der JVM-
Implementierung ab
Seite 35
Prof. Dr. Peter Mandl Seite 36
Scheduling in Java: Strategien
Scheduling ist preemptive
- Thread wird nach einer bestimmten Zeit unterbrochen
(Zeitscheibe)
Scheduling ist „weak fair“:
- Irgendwann einmal kommt jeder Thread dran
Eine Queue je Priorität
- Thread der ganz vorne in Queue mit höchster Priorität
ist, kommt als nächstes dran
- Prioritäten werden für lange wartende Threads erhöht
Prof. Dr. Peter Mandl Seite 37
Überblick
Fallbeispiel: Unix
Fallbeispiel: Linux
Fallbeispiel: Windows
Fallbeispiel: Scheduling in Java
Prof. Dr. Peter Mandl Seite 38
Gesamtüberblick
Einführung in Computersysteme
Entwicklung von Betriebssystemen
Architekturansätze
Interruptverarbeitung in Betriebssystemen
Prozesse und Threads
CPU-Scheduling
7. Synchronisation und Kommunikation
8. Speicherverwaltung
9. Geräte- und Dateiverwaltung
10.Betriebssystemvirtualisierung
Top Related