os v8 scheduling teil 2 print - inf.fu-berlin.de · multilevel feedback queue scheduling vier...
Post on 27-Aug-2019
218 Views
Preview:
TRANSCRIPT
Scheduling
Prof. Dr. Margarita Esponda
Freie Universität Berlin
WS 2011/2012
Teil 2
Multilevel Feedback Queue SchedulingVier Prioritätsklassen
Beispiel:
Höchste Priorität
Niedrigste Priorität
Die Prozesse wandern mit der Zeit nach unten.
Niedrigere Priorität, aber größere Quantum.
Quantum = 4
Quantum = 8
Quantum = 16
FCFS
neue Prozesse
M. Esponda-Argüero
Multilevel Feedback Queue Scheduling
Parameter:
- Anzahl der Warteschlangen.
- Scheduling-Algorithmen für jede Warteschlange.
- Wann können Prozesse zwischen den Warteschlangen
wandern.
- Wo werden neu gestartete Prozesse eingeordnet.
- Wie oft wird Scheduling-Information aktualisiert
- Welches Feedback wird verwendet.
M. Esponda-Argüero
BSD 5.2-Scheduler
✴ Dynamische Prioritäten
✴ nice-Wert. Nettigkeit eines Threads gegenüber den anderen.
"multilevel feedback queue scheduler"
0-20
ich bin sehr nett und gibt CPU-Zeit ab
20
ich bin nicht nett und will mehr CPU-Zeit
er will gleich bleiben
M. Esponda-Argüero
der Prioritätszerfall wird gebremst
die Prioritätszerfall wird beschleunigt
BSD 5.2 - Scheduler
M. Esponda-Argüero
Scheduling-Klassen
0 - 63 ITHD
Priorität Klasse Thread-Type
63 - 127 KERN Top-half kernel
128 - 159 REALTIME Real Time
Botton-half kernel (Interrupt)
160 - 223 TIMESHARE Time-sharing user
224 - 255 IDLE Idle user
.
.
.
160
.
.
.
161
162
222
223
"multilevel feedback queue scheduler"
✴ 64 verschiedene Prioritäten in der Time-sharing-Klasse von 160 (PRI_MIN_TIMESHARE) bis 223 (PRI_MAX_TIMESHARE)
✴ In jedem 4. Zeit-Quantum (ca. 40 Millisekunden) werden die Prioritäten neu berechnet
✴ die Prioritäten fallen linear in Bezug auf die verbrauchte CPU-Zeit
✴ negative nice-Werte verspäten der Zerfall der Priorität von rechenintensiven Threads
✴ Ein-/Ausgabe intensive Threads werden favorisiert
M. Esponda-Argüero
BSD 5.2 Scheduler
Berechnung der Prioritäten im BSD 5.2
Wobei
- nice vom Benutzer gesetzt wird,
- recent_cpu mit einem exponentiell gewichteten gleitenden Durchschnitt approximiert wird
- und PRI_MIN_TIMESHARE = 160
M. Esponda-Argüero
Die Prioritäten werden mit Hilfe der nice und recent_cpu Komponenten der Thread-Struktur berechnet.
user _ priority = PRI _MIN _TIMESHARE −recent _ cpu
4+ 2 ⋅nice
BSD-Scheduler
Berechnung der Prioritäten
M. Esponda-Argüero
✴ pro Tacktzyklus (clock tick) wird recent_cpu um 1 inkrementiert, wenn das Thread gerade ausgeführt wird
✴ jede Sekunde wird in Abhängigkeit der durchschnittlichen Anzahl der Threads (avg_load) des Systems eine Korrektur gemacht
Berechnung des recent_cpu eines Threads:
avg_load ist die durchschnittliche Anzahl von Threads (run-queue + wait-queue) in den letzten 60 Sekunden.
recent _ cput =2 ⋅avg_ loadt2 ⋅avg_ loadt +1
recent _ cput−1 + nice
avg_ loadt =length(run_queuei ) + length(wait _queuei )i= t
i= t−60∑60
BSD-Scheduler
Berechnung der Prioritäten
BSD 5.2 -Scheduler
M. Esponda-Argüero
Wenn ein Thread gerade aus dem Warte-Zustand raus kommt, wird seine recent_cpu wie folgt berechnet:
recent _ cput =2 ⋅avg_ loadt2 ⋅avg_ loadt +1
⎛⎝⎜
⎞⎠⎟
sleep _ timet
recent _ cput−1 + nice
Nehmen wir an, wir haben nur ein Thread mit nice = 0 und Ti = akkumulierte Tackt-Zyklen (Ausführungszeit)
innerhalb des Zeitintervalls i
BSD 5.2 - Scheduler
M. Esponda-Argüero
recent _ cpu = 23T0 = 0,66 ⋅T0
recent _ cpu = 0,66 ⋅ (T1 + 0,66 ⋅T0 ) = 0,66 ⋅T1 + 0,44 ⋅T0
recent _ cpu = 0,66 ⋅T2 + 0,44 ⋅T1 + 0,30 ⋅T0
recent _ cpu = 0,66 ⋅T3 + 0,44 ⋅T2 + 0,30 ⋅T1 + 0,20 ⋅T0
recent _ cpu = 0,66 ⋅T4 + 0,44 ⋅T3 + 0,30 ⋅T2 + 0,20 ⋅T1 + 0,13 ⋅T0
Nach fünf Berechnungen wird der CPU-Verbrauch vor 5 Sekunden fast vergessen.
Lotterie-Scheduling
- von Waldspurger und Weihl
- 1994 entwickelt
- Der Grundgedanke ist hier, einem Prozess Lotterielose
für verschiedene Ressourcen (z.B. CPU-Zeit) zu
geben.
- Wer eine bestimmte Ressource bekommt, wird beim
Ziehen eines Lotterieloses entschieden.
- Prozesse mit höherer Priorität bekommen Extra-Lose.
M. Esponda-Argüero
Lotterie-Scheduling
Interessante Eigenschaften
• Kooperierende Prozesse können Lose austauschen.
• Ein gerade blockierter Client-Prozess kann seine Lose an den Server-Prozess abgeben.
• Server-Prozesse brauchen keine Lose, wenn keine Client-Prozesse vorhanden sind.
• Einige Probleme lassen sich einfacher als mit anderen Methoden lösen .
• Alle Prozesse haben eine Mindestanzahl von Losen, so dass keiner verhungern kann.
M. Esponda-Argüero
M. Esponda-Argüero
"Hybrid Lottery Scheduling"
Implementing Lottery Scheduling:Matching the Specializations in Traditional SchedulersDavid Petrou, Kohn W. Milford und Garth A. Gibson1999
Literatur-Empfehlung:
D. Petroe, K. Milford und G. Gibson
• Kombination der Priorität-Klassen des BSD-Scheduling mit der Lottery-Scheduling
• Dynamische Anpassung der Lose mit Hilfe von Lose-Währungen
• Der Overhead ist größer und die Implementierung komplexer
Stride-Scheduling✴ Waldspurger and Weilhl, 1995
✴ deterministisches fair-share-Scheduling
✴ Tickets anstatt Lotterie-Lose
✴ Viele Tickets bedeute mehr Recht auf CPU-Zeit
✴ Ressourcen werden direkt proportional zur Anzahl von Tickets zugeteilt.
z.B. Ein Prozess, der 10 Tickets hat, bekommt innerhalb einer bestimmten Zeitspanne doppelt so viel CPU-Zeit als einer, der nur 5 Tickets hat.
✴ die Prozesse bekommen immer das gleiche CPU-Quantum
✴ ein Zeitintervall stride, das ein Prozess zwischen den CPU-Zuteilungen warten muss, wird berechnet.
M. Esponda-Argüero
Stride-SchedulingEinfaches Konzept
- CPU-Kapazitäten werden von Prozessen reserviert (Tickets).
- Ein Ticket stell eine minimale CPU-Zeiteinheit dar.
- Jeder Prozess hat ein pass-Wert, der dynamisch berechnet wird.
- Der pass-Wert wächst umgekehrt proportional zu den reservierten CPU-Kapazitäten.
- Das Inkrement des pass-Werts wird stride genannt.
stride1
strideTiticketsTi
=
stride1 = 20
Beispiel:
M. Esponda-Argüero
Stride-Scheduling
Der Scheduler wählt den Prozess mit dem kleinsten pass-Wert
stride1 = 20
Beispiel:
Am Anfang ist der pass-Wert = 0 für alle Prozesse
stride1
strideTiticketsTi
=
Stride-Scheduling
A B C C C A C C A B C
Was passiert, wenn neue Prozesse gestartet oder beendet werden?
Ein pass-Wert muss berechnet werden.
In dem System gibt es einen globalen pass-Wert der aktualisiert wird, indem ein globaler stride-Wert addiert wird.
Quantum
global _ stride = stride1global _ tickets
passTnew = global _ pass + strideTnewM. Esponda-Argüero
Stride-SchedulingProzesse haben auch eine remain-Komponente, die wie folgt berechnet wird:
Prozesse, die aus der Warteliste neu gestartet werden, müssen nur ihre remain-Komponente zum globalen pass-Wert addieren, um ihren eigenen pass-Wert zu berechnen.
Wenn ein Prozess unterbrochen wird, wird ihr pass-Wert mit folgender Formel berechnet.
remain = passTi − global _ pass
passTi = passTi +timeconsumedtimeallocated
⋅ strideTi
M. Esponda-Argüero
Stride-SchedulingAnfangszustand der
Warteschlangen
M. Esponda-Argüero
0
1
2
n
.
.
.
A B C
A
HEAD
B C C B C A C B C
2 3 5
pass 15 10 6 12 20 18 30 24 30 30
Tickets
pass
time
0
6
.
.
.HEAD
10
.
.
.
15
.
.
.
.
.
.
A
C
B
Früheres Linux-SchedulingDer O(1)-Scheduler
- SMP (Symmetric Multiprocessing) - Prozessor Affinität - Lastverteilung- Unterstützung von interaktiven Threads
- real-time-Bereich 0 - 99- nice-Bereich 100 - 140
Priorität
Höhere Prioritäten haben ein längeres Zeitquantum.Niedrigere Prioritäten haben ein kürzeres Zeitquantum.
Höhere Prioritäten
Niedrige Prioritäten
200 ms.…
10 ms.
Quantum
Echtzeit-Tasks bekommen immer eine feste Priorität.Prozesse (Threads) im nice-Bereich haben dynamische Prioritäten, die sich um ±5 verändern können.
M. Esponda-Argüero
Linux-Scheduling (früher)Linux hatte zwei Listen nach Prioritäten sortiert.
Aktive Tasks Ausgelaufene Tasks
[0]
[1]
[2]
.
.
.
[140]
.
.
.
[0]
[1]
[2]
.
.
.
[140]
.
.
.
Tasks, die unterbrochen werden, oder deren Quantum ausgelaufen ist, werden zum Array der ausgelaufenen Tasks geschickt und ihre Priorität wird neu berechnet.
Wenn die Liste der aktiven Tasks leer ist, werden beide Listen vertauscht.
M. Esponda-Argüero
Completely Fair SchedulerNeuer Scheduler von Linux.
Alle Prozesse (mit verschiedenen Prioritäten), die im Bereit-
Zustand sind, werden mit einem einzigen R/B-Baum verwaltet.
Jede CPU hat einen eigenen Scheduler mit einem eigenen R/B-
Baum.
Die Prozesse werden in den Baum nach einer sogenannten
virtuellen Zeit einsortiert, die vom Scheduler jedes Mal neu
berechnet wird.
M. Esponda-Argüero
4 3 1Gewichte
4/8 3/8 1/8
Summe = 8
A B CProzesse
CPU Zeit
Completely Fair Schedulerfrüher
M. Esponda-Argüero
4 3 1Gewichte
4/8 3/8 1/8
Summe = 8
A B CProzesse
CPU Zeit
100%
Completely Fair Scheduler
M. Esponda-Argüero
100% 100%
4 3 1Gewichte
4/8 3/8 1/8
Summe = 8
A B CProzesse
CPU Zeit
8 8 8
Completely Fair Scheduler
M. Esponda-Argüero
Completely Fair Scheduler
virtuelle Laufzeit
braucht mehr CPU-Zeit braucht weniger CPU-Zeit
Nil Nil
27
6
33
31 5024
2
17
Nil Nil Nil Nil29
Nil Nil
NilNil
struct sched_entity{ struct load_weight load;
struct rb_node run_node;struct list_head group_node;...
}
O(log(n))
M. Esponda-Argüero
Multithreading-Architektur von SolarisMany-to-Many Thread-Modell
M. Esponda-Argüero
Thread-Scheduling
- Benutzer-Threads PCS- Kernel-Threads SCS
- one-to-one- many-to-one- many-to-many
Thread-ModelleThread
Threads werden auf sogenannte LWP Prozesse innerhalb des Kernels abgebildet.
PCS Process-contention scopeSCS System-contention scope
In dem SCS-Scheduling konkurrieren alle Threads des Systems für die CPU-Zeit.
Prozess-Thread
Kernel-Thread
M. Esponda-Argüero
Berücksichtigte Threads
Zustellungs-Bereich
Pthread-Scheduling
PTHREAD_SCOPE_PROCESS
PTHREAD_SCOPE_SYSTEM
Scheduling in PCS
Scheduling in SCS
Linux und Mac OS X erlauben nur PTHREAD_SCOPE_SYSTEM
Scheduling in SCS
Zwei Start-Attribute:
PThread-Scheduling
Scheduling in PCS
pthread_attr_setscope(pthread_attr_t *attr, int scope);
pthread_attr_getscope(pthread_attr_t *attr, int *scope);
Berücksichtigte Threads
innerhalb von Prozessen
Berücksichtigte Threads zwischen
Prozessen
Mehrfach-Prozessor Scheduling- Durch moderne Rechnerarchitekturen mit mehreren
Prozessoren wird das Scheduling-Problem komplexer.
- Wir konzentrieren uns auf Systeme mit gleichartigen parallelen Prozessoren.
Mehrfach-Prozessor Scheduling
Asymmetrische
Symmetrische (SMP)
- ein CPU (Master Server) für Systemaktivitäten und
- Ein-/Ausgabe-Aktivitäten.
- andere Prozessoren nur für Benutzerprozesse.
- Die Prozessoren werden selber verplant oder jeder Prozessor hat seine eigene Scheduling- Warteschlange
M. Esponda-Argüero
Mehrfach-Prozessor Scheduling
Kriterien für die CPU-Zuteilung
Affinität
Lastverteilung
„Processor Affinity“
„Load Balancing“
Hart
Weich
Prozesse (Threads) können nur auf bestimmten Prozessoren laufen.
Prozesse (Threads) werden bevorzugt auf den Prozessoren laufen, wo sie zuletzt gelaufen sind.
„push migration“
„pull migration“
Ein Task prüft periodisch die Prozessorlast und teilt die Prozesse neu auf.
Ein unbelasteter Prozessor holt sich selber einen Prozess.
M. Esponda-Argüero
Kontext-WechselDirekte Kosten:
- Speichern und Laden von Registern- Adressraum-Wechsel
Indirekte Kosten: CPU-cache, File-/Page-cache und TLB-misses
CPU Cache
File/Page Cache
T1 T2
Ersetzung-Overhead
M. Esponda-Argüero
Multicore-Prozessor Scheduling
- coarse-grained-Multithreading
- fine-grained-Multithreading
Probleme: Memory stall
Multithreaded multicore system
Zeit
C M C M C M C M Thread1
C M C M C M C M Thread0
CCompute cycle
M Memory stall cycle
Prozessoren warten häufig mehr als 50% der Zeit auf Speicher-Zugriffe
Lösungen:
M. Esponda-Argüero
Solaris SchedulingDas Solaris-Betriebssystem hat:
- Unterstützung von Threads auf Benutzer- und Kernel-Ebene
- Symmetrisches Multithreading
- Echtzeit-Scheduling
Solaris hat einen Scheduler mit Prioritäten und sechs Scheduling-Klassen.
6 Fix Priority (FP)5 Fair share (FSS)4 Real Time (RT)3 System (SYS)2 Interactive (IA)1 Time sharing (FP)
Innerhalb jeder Klasse werden verschiedene Prioritäten und verschiedene Algorithmen verwendet.
M. Esponda-Argüero
Solaris Scheduling-Tabelle für time-sharing und interaktive Threads
Bildquelle: Silverschatz
Die Prioritäten werden umgekehrt proportional
zum Quantum
vergeben.
neue Prioritäten
60 Prioritätsebenen
Solaris Scheduling
Die Default-Klasse ist "time sharing".
Interrupt-Threads
Real-Threads
System-Threads
Fair share-ThreadsFixed priority-ThreadsTimeshare-ThreadsInteractive-Threads
Scheduling-ReihenfolgeGlobale Priorität
höchste
niedrigste
erste
letzte
169
160159
10099
6059
0
M. Esponda-Argüero
Solaris Scheduling
Globale Prioritäten
Scheduling Reihenfolge
Scheduling Klassen
Ausführungs-Warteschlangen
Höchste
Niedrigste
Erste
Letzte
Echtzeit
System
InteraktivTime sharing
..
.
..
.
..
.
Kernel Echtzeit LWPs
Kernel Dienst-Threads
LWPs
Max...0
Max...0
RR-Scheduling
M. Esponda-Argüero
Windows Vista Scheduling
- kein zentraler Thread für das Scheduling
- Wenn ein Thread nicht mehr weiter laufen kann, wechselt er selbst in den Kernmodus und ruft den Scheduler auf.
-Das Quantum ist abgelaufen-Der Thread wird blockiert-Der Thread schickt ein Signal an ein Objekt
Grund?
Systemaufrufe:
SetPriorityClass
SetThreadPriority
Setzt die Prioritäten aller Threads eines Prozesses.
Legt die relative Priorität eines Threads bezüglich der Prioritätsklasse seines Prozesses fest.
M. Esponda-Argüero
Windows Vista Scheduling
Win32 API Prioritätsklassen:
REALTIME_PRIORITY
HIGH_PRIORITY
ABOVE_NORMAL_PRIORITY
NORMAL_PRIORITY
BELOW_NORMAL_PRIORITY
IDLE_NORMAL_PRIORITY
variable Prioritäten
feste Prioritäten
Relative Prioritäten innerhalb der Prioritätsklassen
- TIME_CRITICAL- HIGHEST- ABOVE_NORMAL- NORMAL- BELOW_NORMAL- LOWEST- IDLE
Vordergrund- /Hintergrund- Prozesse
M. Esponda-Argüero
Windows Vista Prioritäten
relativePrioritäten
Bildquelle: Silverschatz
PrioritätsklassenDefault Anfangsprioritäten
Windows Vista Prioritäten- Insgesamt 32 Prioritäten (0-31).
- Das Scheduling-System verwaltet ein Array mit 32 Thread-Listen.
- 0-15 sind Benutzer-Prioritäten
- 16-31 sind System-Prioritäten
Anhebung von Prioritäten
- Wenn I/O- Operationen beendet werden
1 Festplatte
2 eine serielle Verbindung
6 Tastatur
8 Soundkarte
- Wenn ein Prozess auf Semaphore, Mutexe oder andere Ereignisse gerade gewartet hat ( 1-2 Stufen )
M. Esponda-Argüero
Windows Vista Prioritäten
Weitere Veränderungen
Das Scheduling-System verfolgt, wieviel Zeit vergangen ist, seit
ein rechenbereiter Thread zuletzt gelaufen ist.
Nachdem ein bestimmter Schwellenwert erreicht worden ist,
wird seine Priorität um zwei Quanten erhöht, auf maximal 15.
Prioritäten werden kleiner
- Wenn ein Thread sein Quantum beendet (1 Stufe)
Prozesse, die in den Vordergrund gestellt werden, bekommen automatisch eine höhere Priorität.
M. Esponda-Argüero
Java - Scheduling
Ein Java-Thread kann nur unterbrochen werden wenn:
- sein Quantum abgelaufen ist
- weil der Thread auf eine Ein-/Ausgabeoperation wartet
- seine run-Methode zu Ende ausgeführt wurde
Die yield-Methode kann einen Thread unterbrechen, auch
wenn sein Zeitquantum noch nicht abgelaufen ist.
Java-Threads haben eine Priorität von 0 bis 10.
Die 0-Priorität kann nur direkt von der JVM vergeben werden.
M. Esponda-Argüero
Java - Scheduling
Folgende Prioritätskonstanten sind definiert.
Thread.MIN_PRIORITY 1
Thread.MAX_PRIORITY 10
Thread.NORM_PRIORITY 5
Je nachdem in welchem Betriebssystem die JVM läuft, haben
Threads mit gleicher Priorität verschiedene Verhalten.
Prioritäten in Java-Threads können mit Hilfe der setPriority-
Methode verändert werden.
M. Esponda-Argüero
Systemaufrufe für Scheduling
Systemaufruf Beschreibung
nice( ) Change the priority of a conventional process.
getpriority( ) Get the maximum priority of a group of conventional
processes.
setpriority( ) Set the priority of a group of conventional processes.
sched_getscheduler( ) Get the scheduling policy of a process.
sched_setscheduler( ) Set the scheduling policy and priority of a
process.sched_getparam( ) Get the scheduling priority of a process.sched_setparam( ) Set the priority of a process.
sched_yield( ) Relinquish the processor voluntarily without blocking.
sched_get_ priority_min( ) Get the minimum priority value for a policy.
sched_get_ priority_max( ) Get the maximum priority value for a policy.
sched_rr_get_interval( ) Get the time quantum value for the Round Robin policy
Linux
top related