Betriebssysteme. Teil 13: Scheduling

Betriebssysteme Teil 13: Scheduling Betriebssysteme - WS 2015/16 - Teil 13/Scheduling 15.01.16 1

Literatur [13-1] Quade, Jürgen; Mächtel, Michael: Moderne Realzeitsysteme kompakt. dpunkt, 2012 [13-2] Quade, Jürgen: Embedded Linux lernen mit dem Raspberry Pi. dpunkt, 2014 [13-3] Eißenlöffel, Thomas: Embedded-Software entwickeln. dpunkt, 2012 Betriebssysteme - WS 2015/16 - Teil 13/Scheduling 2

Übersicht Zustände für Tasks Scheduling-Strategien Prioritätsinversion Scheduling mit mehreren CPUs Betriebssysteme - WS 2015/16 - Teil 13/Scheduling 3

Scheduler Scheduling = Verfahren der Zuordnung von Betriebsmittel an Task (Zusammenfassung von Threads und Prozessen) Betriebsmittel können sein: CPU Platten/SSD Kritische Abschnitte Scheduler = Komponente im Kernel zur Realisierung eines Scheduling-Verfahrens Zentral für den Scheduler ist ein Plan: Kurzfristige Pläne Mittel/Langfristige Pläne Die Pläne beruhen u.a. auf Task-Zuständen Verbrauchte CPU-Zeit (späteste) Zeitpunkte der Ausführung Betriebssysteme - WS 2015/16 - Teil 13/Scheduling 4

Zustände von Tasks (Konzept) I Zustand Bedeutung running Die Task besitzt gerade die CPU bzw. wird so behandelt, als ob sie läuft. Ort RAM ready Die Task wartet auf die Benutzung der CPU. RAM waiting Die Task wartet auf die Beendigung eines I/O- Vorgangs. RAM sleeping Die Task wartet längere Zeit auf einen Zeitpunkt, an dem sie die CPU haben will. swapped Teile oder die gesamte Task liegen nicht im RAM. RAM Platte SSD Betriebssysteme - WS 2015/16 - Teil 13/Scheduling 5

Zustände von Tasks (Konzept) II running Braun: Kurzfristig create ready waiting sleeping swapped Blau: Mittel/Langfristig Das Terminieren kann aus jedem Zustand heraus erfolgen. Betriebssysteme - WS 2015/16 - Teil 13/Scheduling 6

Linux etwas realistischer Quelle: http://opensourceforgeeks.blogspot.de/2014/03/processes-and-threads-in-linux.html Betriebssysteme - WS 2015/16 - Teil 13/Scheduling 7

Ziele des Schedulings Permanente Ausnutzung der CPU Maximale Anzahl von bearbeiteten Tasks pro Zeiteinheit (Systemdurchsatz) Systemsicht Niedrige durchschnittliche Wartezeit Minimale Antwort-/Reaktionszeit Benutzungssicht Jeder Taskwechsel kostet Zeit, d.h. häufiges Umschalten ist nicht gut. Fairness/Gerechtigkeit Einhaltung von Prioritäten Minimaler Aufwand für das Scheduling selbst Allgemein Betriebssysteme - WS 2015/16 - Teil 13/Scheduling 8

Preemptive und Non-Preemptive Preemptive oder unterbrechendes Scheduling = Es besteht die Möglichkeit, dass ein rechnender Task die CPU abgibt, wenn der Scheduler dies entscheidet. Dies wird manchmal als Entzug der CPU bezeichnet. Non-Preemptive oder nicht unterbrechendes Scheduling = kooperatives Scheduling = Eine rechnende Task gibt die CPU nur explizit geplant ab, wenn sie terminiert, oder sie auf ein Ereignis wartet (I/O, z.b.). Betriebssysteme - WS 2015/16 - Teil 13/Scheduling 9

Zeitpunkte für Scheduling-Entscheidungen Ereignisse einer Task Terminieren Erzeugen Warten auf ein Ereignis, z.b. Beendigung von I/O Erfolgte IPC Warten in einer Semaphore I/O-Interrupt Freiwillige Abgabe der CPU Timer-Interrupt Im folgenden wird nur noch das CPU-Scheduling betrachtet, alle anderen Arten, z.b. Plattenzugriff-Scheduling oder Scheduling des Plattenarms, arbeiten analog. Betriebssysteme - WS 2015/16 - Teil 13/Scheduling 10

Eine Beobachtung Tasks arbeiten fast immer in kurzen Schüben: Burst = Zeitabschnitt, in dem eine Task in einem Stück die CPU benutzt bzw. benutzen will, Deutsch: Stoß In den Pausen dazwischen wird auf ein Ereignis gewartet, meistens auf die Beendigung von I/O. Typisch ist (Beispiel): CPU benutzt Keine CPU I/O I/O Burst Burst Burst Burst Betriebssysteme - WS 2015/16 - Teil 13/Scheduling 11

Überblick Verfahren Batch/Hintergrund-Tasks First-Come-First-Served (FCFS) Shortest Job First (SJF) Shortest Remainung Time Next (SRTN) Interaktive Tasks High Priority First (HPF) Round Robin (RR) Echtzeit-Tasks High Priority First (HPF) Earliest Deadline First (EDF) Betriebssysteme - WS 2015/16 - Teil 13/Scheduling 12

First-Come-First-Served (FCFS) Non-Preemptives Scheduling Burst-Dauer ist bekannt Beispiel Task Burst Zeit T 1 24 Bevorzugung von Langläufern Zum Zeitpunkt der Entscheidung müssen alle Kandidaten bekannt sein T 2 6 T 3 3 T 1 T 2 T 3 T 2 T 3 T 1 Situation 1: Reihenfolge T 1, T 2, T 3 Mittlere Wartezeit: (0+24+30)/3=18 Situation 2: Reihenfolge T 2, T 3, T 1 Mittlere Wartezeit: (0+6+9)/3=5 Betriebssysteme - WS 2015/16 - Teil 13/Scheduling 13

Shortest Job First (SJF) Non-Preemptives Scheduling Burst-Dauer ist bekannt Beispiel Task Burst Zeit T 1 24 Zum Zeitpunkt der Entscheidung müssen alle Kandidaten bekannt sein Bevorzugung von Task mit kurzen Burst-Zeiten T 2 6 T 3 3 T 3 T 2 T 1 Situation 1: Reihenfolge T 1, T 2, T 3 Mittlere Wartezeit: (0+3+9)/3=4 Betriebssysteme - WS 2015/16 - Teil 13/Scheduling 14

Shortest Remaining Time Next (SRTN) I Preemptives Scheduling Burst-Dauer ist bekannt Es bekommt die Task die CPU, die vom ihrem Burst die kürzeste Restzeit noch hat. Variante: Maximale Burst-Dauer wird begrenzt. Jede Task bekommt eine Zeitscheibe als max. Burst-Dauer zugewiesen Betriebssysteme - WS 2015/16 - Teil 13/Scheduling 15

Shortest Remaining Time Next (SRTN) II - Beispiel Task Burst Zeit Ankunft T 1 24 0 T 2 6 2 T 3 3 3 T 1 T 3 T 2 T 1 T 2 T 3 T 2 T 1 SJF ohne Preemptive: Reihenfolge T 1, T 2, T 3 Mittlere Wartezeit: (0+24+27)/3=17 SJF/SRTF mit Preemptive: Reihenfolge T 1, T 2, T 3 Mittlere Wartezeit: (0+2+3)/3=1.7 Die mittlere Wartezeit ist bei SRTF minimal. Beim Preemtive-Scheduling sind die Task-Umschaltungen häufiger, auch verlängert sich die Bearbeitungszeit, dafür sinkt in der Regel die Wartezeit. Betriebssysteme - WS 2015/16 - Teil 13/Scheduling 16

Abschätzung der zukünftigen Burst-Dauer Aus der Vergangenheit lernen, z.b. gewichtete Mittelwertbildung: s n+1 = f*t n +(1-f)*s n s n : Schätzung zum Zeitpunkt n t n : Tatsächliche Burst-Dauer zum Zeitpunkt n f: Faktor zwischen 0 und 1 Ist der Faktor f 0, dann findet kein Lernen statt, denn die Schätzung ist immer gleich. Zu kleine Werte: zu langsame Anpassungen an Trends Ist der Faktor f 1, dann findet kein Lernen statt, denn der letzte tatsächliche Wert ist die zukünftige Schätzung, was zu hektischen Verhalten führt. Zu große Werte: hohe Schwankungen, kaum Glättungen Je größer der Wert für f ist, desto schneller wird die Vergangenheit vergessen. Betriebssysteme - WS 2015/16 - Teil 13/Scheduling 17

High Priority First I Non-Preemptive Der Task mit der höchsten Priorität erhält die CPU und behält sie unabhängig davon, ob inzwischen Tasks mit höherer Priorität die CPU haben wollen, solange bis der Burst beendet ist. Gefahr des Verhungerns niedrig priorisierter Tasks Preemptive Der Task mit der höchsten Priorität erhält die CPU und behält sie solange bis eine Tasks mit höherer Priorität die CPU haben will oder bis der Burst beendet ist. Gefahr des Verhungerns niedrig priorisierter Tasks Betriebssysteme - WS 2015/16 - Teil 13/Scheduling 18

High Priority First II - Praxis Priorität 0 Priorität 1 CPU... Priorität N Die Tasks werden entsprechend ihrer Priorität in Warteschlangen eingereiht. Innerhalb einer Schlange haben alle Tasks dieselbe Priorität: FCFS Eine niedrige Nummer der Schlange bedeutet höhere Priorität. Eine Warteschlange wird abgearbeitet, wenn alle Warteschlangen höherer Priorität leer sind. Dies erfolgt mit/ohne CPU-Entzug (Preemptive). Betriebssysteme - WS 2015/16 - Teil 13/Scheduling 19

High Priority First III - Verhungern Ein niedriger Prioritätswert (Integer) bedeutet höhere Priorität. Um das Verhungern zu verhindern, wird die Wartezeit in eine Erhöhung der Priorität also zu einer Erniedrigung des Integer- Wertes umgewandelt. Dies führt erst zum Nach-Vorne-Schieben in der Warteschlange und dann zum Verschieben in die nächst höhere. Im Extremfall befinden sich alle Tasks in der obersten Warteschlange. Diese Form des High Priority First also das Arbeiten mit Queues gleichberechtigter Tasks wird auch einfach Priority Scheduling genannt. Betriebssysteme - WS 2015/16 - Teil 13/Scheduling 20

Round Robin I Preemptives Scheduling Burst-Dauer ist auf eine Zeitscheibe begrenzt. Alle Tasks sind gleichwertig. Die Reihenfolge bestimmt FCFS. Gerechtes/faires Verfahren Beispiel Task Burst Zeit Ankunft T 1 24 0 T 2 6 2 T 3 3 3 Länge der Zeitscheibe 1 16 2 9 3 5 Nötige Taskwechsel Übliche Größen für Zeitscheiben liegen zwischen 20 und 50 ms. Betriebssysteme - WS 2015/16 - Teil 13/Scheduling 21

Round Robin II Sind die Zeitscheiben sehr kurz, kommt es zu Verlusten durch (zu) viele Task-Wechsel. Sind die Zeitscheiben zu lang, kommt nähert sich Round Robin zur FCFS-Strategie mit Benachteiligung langer Burst-Zeiten. Round Robin kann auch mit der Idee des Shortest Remaining Time Next kombiniert werden, so dass angefangene Zeitscheiben mit höherer Priorität beendet werden: Beendet eine Task aufgrund von Warten vorzeitig seine Zeitscheibe, so kommt sie nach dem Warten vorne in die Queue mit der reduzierten Zeitscheibe (wie bei SRTN). Betriebssysteme - WS 2015/16 - Teil 13/Scheduling 22

Kurzzeitiges Höher-Priorisieren Es gibt gute Gründe für eine kurzzeitige Erhöhung der Priorität: Nach jedem Warten auf I/O, nicht nach einem Warten aufgrund Synchronisation oder nach Warten auf IPC Wenn Interaktivität verbessert werden soll: Nach jedem Warten wird die Priorität kurzzeitig erhöht. Jede Task innerhalb eines kritischen Abschnitts bei Preemptiven Strategien Zur Vermeidung von Priority Inversionen (Echtzeitsysteme) Betriebssysteme - WS 2015/16 - Teil 13/Scheduling 23

Round Robin mit HPF kombiniert Priorität 0 Echtzeit-Tasks Priorität 1 CPU Interaktive Tasks... Priorität N Hintergrund-Tasks Wie bei High Priority First haben die Queues eine Priorität. Innerhalb einer Queue wird mit Round Robin gearbeitet, also mit festen Zeitscheiben. Nach jedem Durchlauf der Queue N wird ein Element aus der Queue N+1 ausgewählt. Eine lange Wartezeit kann durch Wechsel der Queues kompensiert werden. Betriebssysteme - WS 2015/16 - Teil 13/Scheduling 24

Variante mit unterschiedlichen Zeitscheiben I Queue 0 Zeitscheibe 8 ms (Beispiel) Queue 1 Zeitscheibe 16 ms (Beispiel) Queue 2 Round Robin, Zeitscheibe 32 ms (Beispiel) Nach jedem Warten oder nach der Erzeugung kommt die Task in die Queue 0 und erhält 1x nach FCFS eine Zeitscheibe von 8 ms. Reicht dies nicht, kommt die Task in Queue 1 und erhält 1x nach FCFS eine Zeitscheibe von 16 ms. Queue 1 wird nur bei leerer Queue 0 abgearbeitet. Reicht das immer noch nicht, kommt die Task in Queue 2 und erhält nach Round-Robin die CPU, wobei diese Queue nur bei leeren Queues 0 und 1 abgearbeitet wird. Betriebssysteme - WS 2015/16 - Teil 13/Scheduling 25

Variante mit unterschiedlichen Zeitscheiben II Dieses Verfahren ist ein Beispiel für eine Multi-Level-Feedback- Queue. Es bevorzugt Tasks mit kurzen Burst-Zeiten und I/O-intensive Tasks, benachteiligt aber Langläufer. Es gibt noch andere Varianten, z.b. 1) Jede Queue arbeitet nach Round Robin. 2)Beendet eine Task ihre Zeitscheibe mit einem Warten, so verbleibt sie in der Queue (wenn sie im Zustand ready wieder ist). 3)Verbraucht sie die Zeitscheibe und möchte weiterhin die CPU, so wandert sie in die nächst niedrigere Queue. 4)Verbraucht sie dann kurze Zeitscheiben, wird sie wieder höher gestuft. Betriebssysteme - WS 2015/16 - Teil 13/Scheduling 26

Earliest Deadline First (EDF) Wenn Tasks bis spätestens zu einem bestimmten Zeitpunkt gearbeitet haben müssen, wird die Zeit bis zu dieser Deadline zur Grundlage der Bestimmung der Priorität benutzt. Je kürzer diese Zeit, desto höher die Priorität. Dies ist typisch für Tasks, die zyklisch immer wiederkehrende Dinge tun müssen und einen ungefähr immer gleichen Aufwand benötigen. So etwas erfolgt in Realzeitsystemen mit festen Aufgaben. Es wird der späteste Startzeitpunkt berechnet (Deadline Laufzeit) sowie die Zeitdifferenz zu diesem Zeitpunkt. Betriebssysteme - WS 2015/16 - Teil 13/Scheduling 27

Phänomen der Prioritätsinversion I Bei priorisierten Verfahren gibt es noch eine kleine Schwierigkeit: Wenn eine Task mit hoher Priorität auf eine Task mit niedrigerer Priorität warten muss, widerspricht dies der höheren Priorität. Das kann z.b. bei einem p() vor einem kritischen Abschnitt passieren: Task L (mit niedriger Priorität) betritt den kritischen Abschnitt. Dann kommt Task H (mit hoher Priorität), führt das p() zu diesem belegten Abschnitt aus und muss auf Task L warten. Prioritätsinversion = Situation, in der (für eine unzumutbar lange Zeit) eine Task auf eine andere warten muss, die eine niedrigere Priorität besitzt Betriebssysteme - WS 2015/16 - Teil 13/Scheduling 28

Phänomen der Prioritätsinversion II Verschärfung der Situation durch Tasks mit drei Prioritätsstufen: 1) Task L (mit niedriger Priorität) betritt den kritischen Abschnitt. 2)Dann kommt Task H (mit hoher Priorität), führt das p() zu diesem belegten Abschnitt aus und muss auf Task L warten. 3)Task M mit mittlerer Priorität (L<M<H) verdrängt nun Task L, so dass Task H noch länger warten muss. Gegenmaßnahme: Prioritätsvererbung In der obigen Situation erhält eine Task mindestens die Priorität der an der Spitze der Warteliste wartenden Task: 1) Task L (mit niedriger Priorität) betritt den kritischen Abschnitt. 2)Dann kommt Task H (mit hoher Priorität), führt das p() zu diesem belegten Abschnitt aus und muss auf Task L warten. 3)Task L erbt die Priorität H. Nun kann Task M mit mittlerer Priorität die Task L nicht mehr verdrängen. 4)Task L führt das v() aus und erhält wieder seine ursprüngliche niedrige Priorität. Betriebssysteme - WS 2015/16 - Teil 13/Scheduling 29

Phänomen der Prioritätsinversion III Die zeitlich begrenzte Vererbung von Priorität gilt für jegliches Warten auf Ressourcen, z.b.: Warten in p() Warten im receive() auf eine Nachricht Warten auf Freigabe von Speicher... jedoch nicht beim Warten auf I/O. Betriebssysteme - WS 2015/16 - Teil 13/Scheduling 30

Scheduling mit mehreren CPUs I Symmetrisches Multiprocessing = Alle CPUs haben dieselben Fähigkeiten und Geschwindigkeiten Asymmetrisches Multiprocessing = Einige der CPUs sind entweder langsamer als andere oder ihnen fehlen Fähigkeiten, z.b. Floating Point-Operationen Hier wird nur das symmetrische Multiprocessing behandelt. Betriebssysteme - WS 2015/16 - Teil 13/Scheduling 31

Scheduling mit mehreren CPUs II Variante 1 CPU 1 CPU 2...... CPU n Jede CPU hat ihre eigenen Warteschlangen mit entsprechenden Prioritäten bzw. Zeitscheiben. Es wird ein eigenes Scheduling realisiert in einem "virtuellen" Scheduler, der nur für die eine betreffende CPU zuständig ist. Betriebssysteme - WS 2015/16 - Teil 13/Scheduling 32

Scheduling mit mehreren CPUs III Variante 1 Vorteile 1) Cache nach Task-Wechsel hat meistens richtigen Inhalt. 2)Jede CPU hat einen Scheduler, der nur auf seine Queues zugreift, also wenige Kollisionen beim Zugriff auf Scheduling-Tabellen. Nachteile 1)Schlechte Verteilung der Belastung: einige CPUs sind überlastet, andere wenig belastet 2)Interrupts müssen von den CPUs bearbeitet werden, deren Task den I/O-Vorgang gestartet haben. 3) Zuordnung der Timer-Interrupts zu einer CPU muss erfolgen. Die Punkte 2) haben den Sinn, dass möglichst selten mehrere CPUs auf dieselben Datenstrukturen zugreifen. Denken Sie an Syscalls und Interrupts, die Auswirkungen auf die Scheduler-Tabellen haben. Das Ziel: Trennung in separate Bereiche. Betriebssysteme - WS 2015/16 - Teil 13/Scheduling 33

Scheduling mit mehreren CPUs IV Variante 2 CPU 1 CPU 2... CPU n Es gibt nur eine einzige Warteschlange bzw. Schlangensystem für alle CPUs. Ein globaler Scheduler regelt die CPU-Zuteilung. Betriebssysteme - WS 2015/16 - Teil 13/Scheduling 34

Scheduling mit mehreren CPUs V Variante 2 Vorteile 1) Guter Ausgleich der Belastung: alle CPUs sind gleich belastet. 2) Leicht zu implementieren 3) I/O-Interrupts können von beliebiger CPU bearbeitet werden. 4) Timer-Interrupts können von beliebiger CPU bearbeitet werden. Nachteile 1) Cache nach Task-Wechsel hat meistens einen falschen Inhalt. 2)Zu einem Zeitpunkt darf nur ein Scheduler auf einer beliebigen CPU laufen, d.h. die CPUs müssen sich dazu abstimmen. 3)Hohe Wahrscheinlichkeit für Kollisionen beim Zugriff auf Scheduling-Tabellen Betriebssysteme - WS 2015/16 - Teil 13/Scheduling 35

Scheduling mit mehreren CPUs VI Variante 2 Um diese Variante 2 zu verbessern, wird häufig ein Parameter für die "Affinität" eines Tasks zu einer CPU eingeführt. Oder: Bei der Task-Erzeugung wird die ID der CPU, auf der die Task ausschließlich laufen soll, angegeben. Mit diesen beiden Mechanismen wird ein Kompromiss zwischen den beiden Varianten realisiert. Betriebssysteme - WS 2015/16 - Teil 13/Scheduling 36

Nach dieser Anstrengung etwas Entspannung... Betriebssysteme - WS 2015/16 - Teil 13/Scheduling 37