Scheduling
Diese Seite ist Teil des Seminars Advanced Operating System Principles.
Einführung
Scheduling ist generell die Zuteilung begrenzter Ressourcen auf Prozesse. Im folgenden werden 2 "jüngere" Verfahren zur Verbesserung des Scheduling näher betrachtet. Einmal das Verfahren Lottery Scheduling, sowie das Steigern der Clock Interupt Rate. Fachbegriffe in diesem Artikel werden wenn möglich sinnvoll übersetzt.
Lottery Scheduling
Dieses Scheduling Verfahren wurde 1994 von Carl A. Waldspurger entwickelt. Ihm liegt ein zufallsbasierter Ressourcen-Verteilungs-Mechanismus zugrunde, der eine einfache und doch sehr flexible Kontrolle über die relativen Ausführungsraten ermöglicht, da der Zufall über längere Sicht ja keinesfalls zufällig sondern relativ genau ist. Zur Abstraktion wird eine Währung eingeführt, sogenannte Lotterie Tickets. Vor jeder Ressourcenzuteilung wird eine Lotterie durchgeführt, wobei der Prozess, der das Gewinnerticket besitzt, die Ressource für ein fest definiertes Zeitquantum nutzen darf.
Zum visuellen Verständnis ist rechts eine Beispiellotterie angegeben, die den Ablauf verdeutlicht.
Die Ticket Abstraktion bietet einen besonderen Vorteil, das modulare Ressourcen-Management, welches durch 4 Methoden beschrieben wird:
Ticket Transfer
Der Ticket Transfer ermöglicht es Prozessen Tickets an Prozesse, von denen sie abhängig sind, abzutreten. Angenommen in der Beispiellotterie wäre Prozess1 von Prozess3 abhängig, dann würde Prozess3 mit einer relativen Wahrscheinlichkeit von 5/10=0,5 die Ressource zugeteilt bekommen (Prozess 1 nimmt ja nicht an der Lotterie teil). Durch den Ticket Transfer könnte Prozess1 seine 10 Tickets an Prozess3 abtreten, und würde dessen Wahrscheinlichkeit auf 15/20=0,75 erhöhen.
Ticket Inflation
Die Ticket Inflation ermöglicht es einem Prozess selbstständig die Anzahl seiner Tickets zu erhöhen oder zu verringern. Diese Methode setzt vorraus, dass die Prozesse untereinander nicht konkurrieren, da ansonsten jeder Prozess unendlich viele Tickets generieren würde. Im vorherigen Beispiel könnte so Prozess3 selbst die Anzahl seiner Tickets erhöhen, ohne dass dafür eine Kommunikation zum Ticket Transfer nötig wäre.
Ausgleichstickets
Diese Methode soll sicherstellen, dass ein Prozess, der nicht das volle ihm zugeteilte Zeitquantum nutzt, trotzdem die Ressource mit der ihm durch die Tickets zugeteilten relativen Wahrscheinlichkeit nutzen kann. Dazu bekommt er für die nächste Lotterie mehr Tickets in Abhängigkeit der verbrauchten Zeit des aktuellen Quantums. Sollte der Prozess also nach dem halben Quantum die Steuerung abgeben, so erhält er doppelt so viele Tickets für die nächste Lotterie.
Ticket Währungen
Ticket Währungen gewährleisten eine Separierung mehrerer Prozessebenen. Ist schwer zu beschreiben, sollte durch Abbildung 2 aber klar werden. Hier haben 2 Benutzer Alice und Bob eine feste Anzahl base-Tickets, die eine relative Ressourcennutzung von 0,33 zu 0,67 also 1 zu 2 bedeuten, und vergeben für ihre Benutzerprozesse jeweils eine eigene Währung. Damit ist gewährleistet, dass das base-Verhältnis bestand hat, egal was die Benutzer auch tun, auch wenn z.B. Bob einen weiteren Prozess startet, siehe Abbildung 3 mit einem base-Verhältnis von 1 zu 1, bleibt Alice unberührt.
Clock interrupt rate tuning
Dies ist kein weiteres Scheduling Verfahren, sondern eine Technik, die das bisherige Scheduling mit einer winzigen Änderung im Betriebssystem effizienter machen soll. Dabei geht es um die System clock, die vom Betriebssystem gesetzt und als timer interrupt rate verwendet wird, also dessen Reaktionszeit definiert. Diese Uhr lief bis vor einigen Jahren seit knapp 3 Jahrzehnten mit 100 Hz, was damals bei 1-MHz-Computern 10.000 Instruktionen pro Tick entsprach, heute jedoch schon mehr als 10 Millionen Instruktionen sind.
Die Beschränkung auf 100 Hz kann z.B. Auswirkung auf die erreichte Framerate des Xine MPEG viewer haben, und nicht die erwarteten 60 Bilder liefern, siehe Abbildung 4. Die Erklärung dazu liefert das nächste Bild. Xine zeigt ein Frame nur, wenn es bis zur Häfte der Zeit bis das nächste Frame erwartet wird, geliefert wird. Je nachdem wann das erste Frame geliefert wird, fällt in 50% aller Fälle 1/3 der Bilder unter den Tisch, was zu einer Framerate von nur 40 Bildern/s führt.
Also stellt sich die Frage, warum man die Frequenz der Systemuhr nicht mit steigender Frequenz der Hardwareuhr erhöht hat - erst mit dem Linux Kernel 2.6 wurde sie auf 250 Hz angehoben. Die Antwort damals war einfach der steigende Overhead, der zwangsläufig bei einer erhöhten Frequenz anfällt. Eine Untersuchung dessen zeigt jedoch, siehe Abbildung 6, dass der höhere Aufwand durch Rechenzeit und verlorene Caches relativ klein bei aktuellen Rechensystemen ausfällt, bei einer Steigerung auf 1000Hz sogar fast zu vernachlässigen ist.
Einen weitereren Vorteil einer höheren Frequenz zeigt Abbildung 7. Die Billing ratio zeigt das Verhältnis der durch den Scheduler berechneten Zeit durch die wirklich genutzte Zeit, Missed quanta hingegen den prozentualen Anteil der nicht durch den Scheduler berechneten Zeitquanten. Da der Scheduler ja nur mit einer bestimmten Frequenz läuft, muss er annehmen, dass der Prozess, der gerade die Ressource nutzt, die Ressource auch die gesamte Zeit bis zum vorherigen Tick genutzt hat, auch wenn das nur sehr selten wirklich der Fall ist. Auffällig hierbei ist, dass trotz einer extrem hohen Missed quanta Wert, sich die Billing Ratio nahe 1 befindet. Das zeigt den guten Ausgleich zu der hohen Überbewertung der kurzen Quanta, die direkt auf einem Tick des Schedulers liegen. Der niedrige Wert der Billing ration des X Servers liegt daran, dass er mit der Systemuhr synchron läuft, also direkt nach dem Scheduler Tick an der Reihe ist, und somit fast nie für seine genutzte Rechenzeit bezahlen muss. Durch eine Erhöhung der Systemuhr Frequenz sinkt also die Zahl der nicht bewerteten Quanten, ebenso wie die Überbewertung kleiner Quanten sinkt, womit sich die Billing ratio weiter an 1 annähert.
Zum Auslesen der System Clock unter Windows gibt es ein kleines Tool von Sysinternals: ClockRes, welches mir bei WinXP SP2 eine Frequenz von 64 Hz und bei Windows 2000 SP4 100Hz ausgibt.
Quellen
- Carl A. Waldspurger and William E. Weihl. Lottery Scheduling: Flexible Proportional-Share ResourceManagement. In Proceedings of the 1st USENIX Symposium on Operating Systems Design and Implementation (OSDI), pages 1–11, November 14–17 1994.
- Etsion, Yoav; Tsafrir, Dan; Freitelson, Dror G. Effects of Clock Resolution on the Scheduling of Interactive and Soft Real-time Processes. In SIGMETRICS ’03 S. 172 - 183.
- Andi Drebes Schedulingalgorithmen und Rechenzeitverteilung auf Betriebssystemebene