Implementierung eines Schedulings mit dynamischer Lastverteilung für die SHAP-Mehrkernarchitektur Diplomarbeit an der FAKULTÄT INFORMATIK DER TECHNISCHEN UNIVERSITÄT DRESDEN eingereicht am: INSTITUT FÜR TECHNISCHE INFORMATIK PROFESSUR FÜR VLSI-ENTWURFSSYSTEME, DIAGNOSTIK UND ARCHITEKTUR von: Peter Ebert geboren am 19. Sep. 1985 in Dresden Matrikel-Nr.: 3129797 Bearbeitungszeitraum: vom 15.05.2012 bis 15.01.2013 Betr. HSL: Betreuer: Prof. Dr.-Ing. habil. Rainer G. Spallek Dr.-Ing. Martin Zabel Dresden, 15. Januar 2013
Ehrenwörtliche Erklärung Ehrenwörtliche Erklärung Hiermit erkläre ich, dass ich die vorliegende Arbeit selbständig und ohne Benutzung anderer als der angegebenen Hilfsmittel angefertigt sowie die aus fremden Quellen direkt oder indirekt übernommenen Gedanken als solche kenntlich gemacht habe. Die Arbeit wurde bisher in gleicher oder ähnlicher Form keiner anderen Prüfungsbehörde vorgelegt und auch noch nicht veröffentlicht. Peter Ebert, Dresden, 15. Januar 2013
Inhaltsverzeichnis I. Inhaltsverzeichnis I. Inhaltsverzeichnis... i II. Tabellenverzeichnis... iii III. Abbildungsverzeichnis... v IV. Abkürzungsverzeichnis... vii 1 Einleitung... 1 1.1 Die SHAP-Mehrkernarchitektur... 1 1.2 Zielsetzung... 1 1.3 Arbeitsumgebung... 2 1.4 Struktur der Arbeit... 2 2 Grundlagen... 3 2.1 Überblick: Load-Balancing... 3 2.2 Überblick: Thread-Scheduling... 7 2.2.1 Terminologie und Charakteristika... 7 2.2.2 Klassische Scheduling-Strategien... 10 2.2.3 Scheduling in Java... 13 2.3 Scheduling auf Mehrkernprozessoren... 14 2.3.1 Scheduling von Threadgruppen... 14 2.3.2 Distributed Weighted Round-Robin... 15 2.4 Relevante Organisation des SHAP-Mehrkernprozessors... 16 2.4.1 Architektur des SHAP-Mehrkernprozessors... 16 2.4.2 Scheduling auf dem SHAP Mehrkernprozessor... 21 3 Entwurf... 23 3.1 Ambitionen... 23 3.2 Fortführung des aktuellen Ansatzes... 23 3.3 Auswahl des Algorithmus... 25 3.3.1 Klassische Algorithmen... 25 3.3.2 Gang Scheduling... 26 3.3.3 Distributed Weighted Round-Robin... 29 3.4 Hardwarearchitektur der Lastmigration... 35 3.4.1 Basisentscheidung... 35 3.4.2 Kommunikationskonzept... 36 i
Inhaltsverzeichnis 4 Implementierung... 41 4.1 Der Scheduler... 41 4.2 Beginn der Migration... 46 4.2.1 Migration- und Yield-Lock... 46 4.2.2 Garbage-Collector-Lock... 48 4.3 Kern- und Thread-Auswahl... 50 4.4 Dialog der Kerne... 50 4.4.1 GC-parallele Buskommunikation... 50 4.4.2 Anrede des Lastkerns... 51 4.4.3 Vorbereitung der Stackübertragung... 53 4.4.4 Stackübertragung... 53 4.4.5 Abschluss der Stackübertragung... 56 4.5 Nachbehandlung... 57 4.5.1 Rückkehr in den Java-Code... 57 4.5.2 Umtragen des migrierten Threads... 57 4.5.3 Aufhebung der Locks... 59 5 Evaluation... 63 5.1 Funktionalität... 63 5.2 Ressourcen... 64 5.3 Leistungsbewertung... 67 5.3.1 Benchmarkbasis... 67 5.3.2 Test des ungünstigsten Falls... 68 5.3.3 Test des günstigsten Falls... 70 6 Abschlussbetrachtung... 75 6.1 Ausbaumöglichkeiten und Ausblick... 75 6.1.1 Transparente Migration... 75 6.1.2 Wichtige Nachbesserungen... 75 6.1.3 Weitere Nachbesserungen... 76 6.2 Zusammenfassung und Fazit... 77 V. Literaturverzeichnis... 79 VI. Anhang... 82 ii
Tabellenverzeichnis II. Tabellenverzeichnis Tab. 2-1: Klassifikation dynamischer Lastverteilungsverfahren nach Pollak... 4 Tab. 5-1: Tab. 5-2: Tab. 5-3: Überblick über die wichtigsten Änderungen im absol. und relat. Hardware- Verbrauch... 65 LUT-Verbrauch ausgewählter veränderter bzw. neu erstellter VHDL- Komponenten... 67 Vergleich des Speed-Ups der alten Version mit dem maximalen theoretischen und dem durch Migration erreichten Speed-Up... 72 iii
iv
Abbildungsverzeichnis III. Abbildungsverzeichnis Abb. 2-1: Klassifikation von Lastbalancierungsverfahren nach Casavant und Kuhl... 5 Abb. 2-2: Architektur des SHAP auf dem Virtex-5 LXT ML505 FPGA... 18 Abb. 2-3: Architektur eines SHAP-Prozessorkerns unter bes. Berücksichtigung des Stacks... 20 Abb. 3-1: Threadverteilung nach aktuellem Ansatz (a) und nach Rundenlänge (b)... 24 Abb. 3-2: Gang Scheduling mit optimalem Packen vor (a) und nach (b) der Terminierung von Programm B und je einem Thread der Programme A und C. Quantum = 1 ms.... 27 Abb. 3-3: Benchmark-Ergebnisse zur Anzahl von Migrationen pro Runde verschiedener Varianten des abgewandelten DWRR-Algorithmus... 33 Abb. 3-4: Diagramm des Kommunikationsablaufs einer erfolgreichen Migration... 37 Abb. 3-5: Verkettung der Stackblöcke bei Migration von Thread 2... 39 Abb. 4-1: Ablaufdiagramm des Schedulers im Mikrocode... 45 Abb. 4-2: Ablauf der Kommunikation über den GC-Bus und der zur Migration wichtige Ausschnitt des GC-Bus-Protokolls... 52 Abb. 4-3: Aufbau eines Datenregisters bei dessen Migration... 54 Abb. 4-4: Zustandsabfolge während der Stackübertragung... 56 Abb. 4-5: Architektur des neuen SHAP-Prozessorkerns mit Lastmigration (rote Linien: Änderung; rote Bezeichnungen: Neuerstellung)... 61 Abb. 4-6: Zeitlicher Kommunikationsablauf einer erfolgreichen Thread-Migration über die Programmierungsebenen Java-Code, Mikrocode und Hardware... 62 Abb. 5-1: Vergleich des Ressourcenverbrauchs im Mikrocode zwischen der ursprünglichen (Original) und der neuen, migrationsfähigen Version (Migration)... 64 v
Abbildungsverzeichnis Abb. 5-2: Vergleich des relativen Hardware-Verbrauchs zwischen der ursprünglichen und der neuen, migrationsfähigen Version... 66 Abb. 5-3: Vergleich der Berechnungszeiten von Crypt zwischen alter (Original) und neuer Version (Migration) im Fall der günstigsten Bedingungen für die alte Version... 69 Abb. 5-4: Vergleich der Berechnungszeiten von SparseMatmult zwischen alter (Original) und neuer Version (Migration) im Fall der günstigsten Bedingungen für die alte Version... 69 Abb. 5-5: Vergleich der Berechnungszeiten von Crypt zwischen alter (Original) und neuer Version (Migration) im Fall der günstigsten Bedingungen für die neue Version... 71 Abb. 5-6: Vergleich der Berechnungszeiten von SparseMatmult zwischen alter (Original) und neuer Version (Migration) im Fall der günstigsten Bedingungen für die neue Version... 71 vi
Abkürzungsverzeichnis IV. Abkürzungsverzeichnis API ASIC CPU CVS CWB DMA DMS DPRR DWRR EDF EWB FCFS FFD FIFO FPGA GC GCB HRRN IDEA IWB JDK JRE JVM JVM-CP LCD LED LLF LUT MC MLFBQ Application Programming Interface Anwendungsspezifische Integrierte Schaltungen Central Processing Unit Concurrent Versions System Core-Wishbone-Bus Direct Memory Access Deadline Monotonic Scheduling Dynamic Priority Round-Robin Distributed Weighted Round-Robin Earliest Deadline First Externer Wishbone-Bus First Come First Serve First Fit Decreasing First In First Out Field Programmable Gate Arrays Garbage Collector Garbage-Collector-Bus Highest Response Ratio Next International Data Encryption Algorithm Interner Wishbone-Bus Java Development Kit Java Runtime Environment Java-Virtual-Machine JVM Constant Pool Liquid Crystal Display Leuchtdiode Least Laxity First Lookup-Tabelle Mikrocode Multilevel Feedback Queue Scheduling vii
Abkürzungsverzeichnis MLQ MMU NOS RAM RMS RR SHAP SJF SMP SPF SPT SRTF TLB TOS UART UMA VHDL VLSI VRR Wichtg. WRR verbl. Qu. ZPU Multilevel Queue Scheduling Memory Management Unit Next on Stack Random Access Memory Rate Monotonic Scheduling Round-Robin Secure Hardware Agent Platform Shortest Job First Symmetric Multi-Processing Shortest Process First Shortest Processing Time Shortest Remaining Time First Translation Look-Aside Buffer Top of Stack Universal Asynchronous Receiver Transmitter Uniform Memory Access Very High Speed Integrated Circuit Hardware Description Language Very-Large-Scale Integration Virtual Round-Robin Wichtung Weighted Round-Robin verbleibende Quanten Zylin CPU viii
Einleitung 1 Einleitung 1.1 Die SHAP-Mehrkernarchitektur SHAP ist ein Projekt des Lehrstuhls VLSI-Entwurfssysteme, Diagnostik und Architektur der Technischen Universität Dresden, das 2006 ins Leben gerufen wurde und bedeutet: Secure Hardware Agent Platform. Bereits im Namen stehen die drei wesentlichen Aspekte von SHAP. Ziel des Projekts ist die Entwicklung einer Agenten-Plattform, welche komplexe Aufgaben verteilt lösen soll. Dazu wird die Programmiersprache Java genutzt. Sie bietet neben Plattformunabhängigkeit auch wichtige Sicherheitsmerkmale. Um echtzeitfähig zu sein, wird SHAP direkt in Hardware implementiert und ersetzt somit die originale Java-Virtual-Machine (JVM), die gewöhnlich auf einem Betriebssystem aufsetzt. Anwendungsspezifische Integrierte Schaltungen (ASICs) können diese Hardware stellen. Aus Forschungsgründen werden aktuell programmierbare Schaltkreise, um genau zu sein Field Programmable Gate Arrays (FPGAs), verwendet. Bei der Prozessorentwicklung geht der Trend zur Steigerung der Leistung in den letzten Jahren weg von der Erhöhung der Taktfrequenz hin zur Erhöhung der Kernanzahl. Analog zu konkurrierenden Java-Prozessor-Ansätzen verfolgte auch das SHAP-Projekt seit 2007 das Ziel mehrere Prozessorkerne zu verwenden. Die Dissertation von Martin Zabel aus dem Jahr 2011 mit dem Titel Effiziente Mehrkernarchitektur für eingebettete Java-Bytecode-Prozessoren [Zab11] beschreibt ausführlich den Werdegang dieser Entwicklung, die Unterschiede zum Einkernprozessor von 2006 und eine umfassende Leistungsbewertung. 1.2 Zielsetzung Die Motivation dieser Arbeit im großen Kontext ist die Verbesserung der SHAP- Mehrkernarchitektur. Die oben erwähnte Doktorarbeit selbst formuliert dafür bereits Ansatzpunkte. Einer dieser Vorschläge ist die Einbindung einer Lastverteilung durch eine dynamische Umverteilung der Threads auf den Kernen. Zusätzlich dazu muss auch eine Anpassung der Thread-Scheduling-Strategie in Betracht gezogen werden, da Scheduling und Load-Balancing auf Mehrkernprozessoren eng miteinander zusammenhängen. Allerdings wurde während dem Literaturstudium ersichtlich, dass zumindest in einigen Quellen die Begriffe Load-Balancing und Load-Migration disjunkte Bedeutungen 1
Einleitung besitzen, und das Ziel dieser Arbeit laut den persönlichen Absprachen mit Load- Migration besser beschrieben ist. Die Realisierung einer Lastmigration ist im Folgenden daher das primäre Vorhaben. 1.3 Arbeitsumgebung Im Rahmen dieser Diplomarbeit wird die aktuelle SHAP-Version, vom lehrstuhlinternen CVS-Server, vom 12. Juni 2012 auf einem Virtex-5 LXT ML505 FPGA der Firma Xilinx genutzt und erweitert. Inbegriffen sind darin sämtliche für die Arbeit relevanten und zu modifizierenden Komponenten, wie die VHDL-Beschreibungen (Very High Speed Integrated Circuit Hardware Description Language), die aktuellen Byte- und Mikrocodes und die Klassenbibliothek. Der Arbeitsplatzrechner besitzt einen 64 Bit Intel Core 2 Duo E8400 Prozessor und wurde mit Microsoft Windows 7 Professional 64 Bit + Service Pack 1 ausgestattet. Jede Kommunikation mit dem Board wird über die serielle UART-Schnittstelle (Universal Asynchronous Receiver Transmitter) bewältigt, wobei das Programm HTerm 0.8.1beta zum Einsatz kam. Java Runtime Environment (JRE) und Java Development Kit (JDK) sind in der Version 1.7.0_03 installiert und als Entwicklungsumgebung wird Eclipse 4.2 (Juno) verwendet. Zur Programmierung des Virtex-5 Boards wird Xilinx ISE Design Suite 13.4 benutzt. 1.4 Struktur der Arbeit Zunächst sollen in Kapitel 2 die theoretischen Grundlagen geklärt werden. Dazu gehören die Auseinandersetzung mit dem gegenwärtigen Stand des SHAP-Projekts sowie ein umfangreiches Studium zur Theorie von Scheduling- und Lastverteilungsstrategien, aber auch bereits bestehender konkreter Algorithmen. Anschließend wird in Kapitel 3 der Weg der Entscheidungsfindung beschrieben, wie und aus welchen Gründen heraus die gestellte Aufgabe gelöst werden soll. Mit der tatsächlichen Implementierung dieser Lösung in die SHAP-Plattform beschäftigt sich Kapitel 4. Kapitel 5 stellt die Ergebnisse der Leistungstests der entstandenen Modifikation dar und vergleicht diese mit der Ausgangsversion. Abschließend wird in Kapitel 6 die gesamte Arbeit auf ihre wichtigsten Bestandteile und Erkenntnisse zusammengefasst und ferner auch durchaus kritisch über etwaige verbesserungsfähige und verbesserungsbedürftige Punkte gesprochen. 2
Grundlagen 2 Grundlagen Zum Verständnis, welchen Möglichkeiten, aber auch Grenzen man bei der Arbeit an einem Scheduling-Algorithmus begegnet, sollen zunächst etablierte Begriffe und Kategorisierungen vorgestellt werden. Eine Vollständigkeit der Angaben wird dabei nicht beansprucht. Zumal die Vollzähligkeit in Anbetracht der gebräuchlichen Bezeichnungen und Einordnungen und der Menge verschiedener Lösungen gar nicht möglich ist. Abschließend wird die Architektur der Mehrkernversion des SHAP-Bytecode-Prozessors vorgestellt, in der der neue Scheduler mit Lastverteilung integriert werden soll. 2.1 Überblick: Load-Balancing Lastverteilung wird im allgemeinen Sinn in sehr vielen Bereichen angewendet. Zur Lösung der Aufgabenstellung interessiert speziell die Verteilung der Rechenlast auf Recheneinheiten. Die Weiterentwicklung des SHAP-Einkernprozessors hin zum Mehrkernprozessor schuf die Notwendigkeit für ein Verteilungsverfahren der Threads. Zum Thema Lastverteilung soll vorerst die geläufige Theorie geklärt und zusammengefasst werden. Dabei sollen asymmetrische Systeme vernachlässigt und nur UMA- (Uniform Memory Access) und gleichzeitig SMP-Architekturen (Symmetric Multi Processing) betrachtet werden, auf denen Threads auf allen Kernen gleichartig ausgeführt werden und auf den Hauptspeicher gleich zugreifen können, wie es auch bei der SHAP- Mehrkernarchitektur der Fall ist. Verfahren zur dynamischen Lastbalancierung müssen folgende fünf Teilentscheidungen treffen [Pol99]. Informationsbasis: Aufgrund welcher Informationen wird die Entscheidung getroffen, Last umzuverteilen? 1 Transferentscheidung: Wann und von wem wird entschieden, ob der Ausgleich stattfindet? Migrationsraum: Gibt es abgegrenzte Bereiche, wohin Last verschoben werden darf oder wohin nicht? Lokationsentscheidung: Zwischen welchen Knoten wird die Last übergeben? Auswahlentscheidung: Wie viel Last und welcher Teil davon wird abgegeben? 11 Das Kapitel 3 der Dissertation von Pollak beschäftigt sich intensiv mit der Beantwortung dieser Frage und stellt dazu ein theoretisches Konzept der Informationsebenen auf. [Pol99] 3
Grundlagen Aufbauend auf den Möglichkeiten und Variationen diese Fragen zu beantworten, entstehen verschiedene Strategien. Um sie einzuordnen, wurden mehrere Klassifikationsschemata entwickelt, von denen nun zwei vorgestellt werden sollen. Die von Rainer Pollak in seiner Dissertation [Pol99] verwendete Taxonomie setzt kongruent auf den fünf oben erwähnten Teilentscheidungen auf und ist in Tabelle 2-1 schematisch mit den jeweils möglichen Ausprägungen dargestellt. Tab. 2-1: Klassifikation dynamischer Lastverteilungsverfahren nach Pollak Informationsbasis Transferentschei- Migrationsraum Lokationsent- Auswahlentschei- dung scheidung dung lokal zentral bereichsbe- zentral zentral bereichsbe- dezentral schränkt dezentral dezentral schränkt global global Die wohl meist verbreitete [Pol99] alternative Klassifikation wurde 1988 von Casavant und Kuhl aufgestellt [CK88] und mit den Jahren erweitert [Pol99]. Sie betrachtet alle Lastbalancierungsverfahren. Gewöhnlich bezieht man sich dabei aber nur auf den in Abbildung 2-1 dargestellten konsistenten, hierarchischen Teil der Gliederung. Für die vorliegende Arbeit ist deren Teilbaum der dynamischen Lastbalancierungsverfahren wichtig. Dabei werden dezentrale Verfahren, bei welchen Knoten ohne Lastinformationen anderer Knoten entscheiden, als autonom bezeichnet. Im Gegensatz dazu nutzen kooperative Verfahren diese Informationen für ihre Entscheidung. Auf der untersten Ebene werden approximative Methoden abgegrenzt. Sie basieren auf einem vollständigen Modell, das in der Lage ist eine optimale Lösung zu generieren, geben sich aber mit einer akzeptabel guten Lösung zufrieden, um sich Zeit für die Suche zu sparen. Die weiteren Unterkategorien sollten bekannt bzw. selbsterklärend sein. 4
Grundlagen Lastverteilung lokal global statisch dynamisch optimal suboptimal zentral dezentral approximativ heuristisch empfängerinitiiert senderinitiiert hybrid kooperativ autonom verschiedene Modelle optimal suboptimal approximativ heuristisch Abb. 2-1: Klassifikation von Lastbalancierungsverfahren nach Casavant und Kuhl Als dynamisches Load-Balancing wird in Anbetracht einer geradezu babylonische[n] Sprachverwirrung [Pol99] eigentlich die Verteilung bei Entstehung von Threads bezeichnet. Im Gegensatz dazu bedeutet Lastmigration die Umverteilung nach Änderung des Lastgleichgewichts. Wenn auch eine gute initiale Zuweisung von hohem Wert ist, ist besonders die komplexere Lastmigration interessant und wesentlich, um auf Dauer hohe Performance zu erreichen. Migriert werden muss lediglich in Systemen mit privaten Thread-Warteschlangen ( ready -Queues) pro Kern. Gibt es eine gemeinsame Warteschlange für das ganze System, nimmt sich ein unbenutzter Kern einfach den ersten Thread aus der Schlange. Private ready -Queues werden jedoch gerade in modernen SMP-Systemen fast ausschließlich genutzt [SGG05]. In einem solchen Umfeld kann Lastmigration auf zwei Arten erfolgen. Entweder überwacht ein einziger, globaler Thread das Gleichgewicht und entscheidet zentral über den empfangenden Kern (push-migration) oder eben dieser Kern sucht sich im Leerlauf eigenständig einen wartenden Thread eines ausgelasteten Kerns (pull-migration). Diese Betrachtungsweise deckt sich nicht ganz mit der Taxonomie von Casavant und Kuhl. Zwar entspricht die empfängerinitiierte Kategorie der pullmigration, die meisten Quellen ordnen jedoch push-migration als dessen Komplement ein, also eine übergeordnete Entscheidungsstelle und nicht die senderinitiierte Kategorie. Pull- und push-migration können auch nebeneinander (hybrid) eingesetzt werden. Es ist allerdings darauf zu achten, dass sogenanntes Thrashing (engl.: das Flattern, das Zittern) vermieden wird, bei dem Kerne überwiegend damit beschäftigt 5
Grundlagen sind Last abzustoßen, weil zum Beispiel alle Kerne überlastet sind [Web01]. Der Schwellwert einer Migration sollte sorgfältig festgelegt werden, da die Last im Allgemeinen immer ein wenig ungleich verteilt ist und dabei schnell schwankt. Außerdem beschränken sich die Kosten der Überführung eines Threads nicht nur auf die benötigte Zeit des Datentransfers. Besonders eventuell auftretende Cache- und TLB-Misses auf dem neuen Kern und die Verzögerung beim Nachladen der Daten aus einem Speicher tieferer Hierarchieebene schlagen sich negativ auf die Gesamtleistung nieder. Um Cache-Misses zu vermeiden, werden sogenannte Prozessor-Affinitys (engl.: affinity = Vorliebe, Zugehörigkeit) verwendet [TMu03]. Threads werden dabei bestimmten Kernen zugeteilt, die sie bei harten Affinitäten nicht mehr, oder bei weichen Affinitäten nur im Extremfall verlassen. Load-Migration kann den Affinitäten allerdings entgegenwirken, was noch ein Grund ist, die Migrationsschwelle mit Vorsicht festzulegen. Der Ablauf einer Thread-Migration hat wesentlichen Einfluss auf die benötigte Zeit und damit auf die Gesamtleistung. Hierbei müssen einige Bedingungen eingehalten werden, um eine exaktes Abbild zu erzeugen. Zuerst muss der Speicherinhalt übertragen werden, was die meiste Zeit beansprucht [DG97], und im Folgenden auch der Zustand des Threads. Gleichzeitig müssen seine Kommunikationsbeziehungen aufrechterhalten werden. Nachfolgend werden drei allgemeine Migrationsabläufe vorgeschlagen, die jeweils mit der Migrationsentscheidung beginnen [Web00]. Intuitiv: Es wird ein günstiger Zeitpunkt für das Einfrieren des Threads abgewartet. Anschließend wird der Threadspeicher und der Threadstatus kopiert. Bevor der originale Thread entfernt wird, werden alle bis dato gesammelten Nachrichten zum Duplikat übertragen und die Kommunikationskanäle umgeleitet. Erst dann kann die Kopie aktiviert werden. Pre-Copying: Im Vergleich zur intuitiven Methode gibt es nur einen Unterschied. Das Ziel ist hierbei die Verkürzung der Totzeit. Noch vor dem Einfrieren des Threads wird sein Speicherinhalt kopiert, weshalb bearbeitete Seiten zwar nach dem Anhalten noch aktualisiert werden müssen. Dies kostet alles in allem aber weniger Zeit als im gestoppten Zustand. Post-Copying/Copy-on-Reference: Zunächst werden alle Speicherseitenzugriffe gesperrt. Beim nächsten auftretenden Seitenfehler wird der Thread gestoppt und diese Seite samt Threadstatus zum Zielknoten kopiert. Dort wird der Thread sofort aktiviert. Bei weiteren Seitenfehlern werden diese vom Quellknoten nachgeladen, sodass ein minimaler neuer Threadspeicher entsteht. 6
Grundlagen 2.2 Überblick: Thread-Scheduling 2.2.1 Terminologie und Charakteristika Unter Scheduling (engl.: schedule = Ablaufplan; to schedule = einteilen) wird das Erstellen eines Ablaufplans verstanden, der eine begrenzte Ressource zuweist. Im Falle des Thread-Scheduling (oft auch Prozess-Scheduling) wird die Rechenzeit eines Prozessors unter mehreren Programm-Threads verteilt. Der Scheduler ist allerdings nur für die Auswahl des zu bearbeitenden Threads zuständig. Die Umschaltung zwischen dem laufenden und dem vom Scheduler ausgewählten Thread übernimmt der Dispatcher. Threads können auf drei zeitliche Arten geplant werden. Die langfristige Planung entscheidet, ob ein Thread überhaupt in den Pool der auszuführenden Threads aufgenommen wird. Mittelfristig wird entschieden, ob diese Threads in den Hauptspeicher geschrieben werden, und die kurzfristige Planung verteilt die Rechenzeit des Prozessors [Ola12]. Für diese Arbeit an SHAP ist nur das kurzfristige Scheduling zu betrachten, da die oberste Stufe der Speicherhierarchie der Hauptspeicher ist und somit keine Daten je ausgelagert sind. Man unterscheidet dabei im Wesentlichen sechs Kriterien, die gute Thread-Scheduling-Algorithmen anvisieren [Bra03]. Es sind Fairness: Dabei soll kein Thread gegenüber anderen Threads unverhältnismäßig lange warten. Eine einheitliche, messbare Definition des schwammigen Fairness- Begriffs wird allerdings nicht vorgeschlagen und somit sind auch Vergleiche verschiedener Scheduling Strategien und Algorithmen dahingehend nur bedingt möglich. Zumeist bedeutet Fairness die im Mittel gleiche Prozessorzeit pro Thread. In Anbetracht deutlich unterschiedlicher Mengen an Arbeit, die ein Thread bearbeiten soll, und möglicher zusätzlicher Prioritäten, überzeugt diese Interpretation von Fairness allerdings nicht, um komplexe Verhältnisse gerecht zu verwalten. Effizienz: Jeder Prozessor ist stets vollständig ausgelastet. Im Kontext realer Programme und damit der Nutzung der Peripherie im PC bzw. auf dem FPGA sollten weitere Ressourcen betrachtet werden. Die ineffiziente Zuteilung der Peripherie kann dazu führen, dass wartende Threads die Ausführung anderer Threads durch die Reservierung anderer Ressourcen als die CPU blockieren und somit der Prozessor nicht ausgelastet wird. Antwortzeit: Die mittlere Wartezeit für Benutzer oder andere Systeme soll minimiert werden. Hintergrundthreads, die keine Interaktion erfordern, werden dabei benachteiligt. 7
Grundlagen Wartezeit: Ziel ist die Minimierung der Zeit, in der ein Thread in Warteschlangen verbringt, sei es im ausführungsbereiten oder blockierten Zustand [Ola12]. Scheduling-Strategien können im Wesentlichen nur die Wartezeit direkt beeinflussen [Bra03]. Verweil-/Ausführungs-/Durchlaufzeit: Wartezeit + Bearbeitungszeit (Bedienzeit). Die Zeit, bis ein gestarteter Thread abgearbeitet ist, soll minimiert werden. Durchsatz: Die Anzahl abgearbeiteter Threads pro Zeiteinheit soll maximiert werden. Allerdings muss in Anbetracht der häufig anzutreffenden Theorie einer konstanten Bedienzeit die Frage gestellt werden, ob und wie sich die Maximierung des Durchsatzes, die Minimierung der Verweilzeit und die Minimierung der Wartezeit unterscheiden und wie sinnvoll diese Abgrenzung ist, selbst wenn die Bedienzeit leicht schwanken würde. Als weiteres Kriterium kann der Overhead, also die Zeit für die Scheduling-Entscheidung und den Kontextwechsel, angesehen werden. Denn je nach Implementierung ist der Scheduler dabei selbst als Thread realisiert und verbraucht entsprechend Rechenzeit [Esp11]. Alle Kriterien lassen sich in zwei Dimensionen einteilen. Erstens benutzer- oder systemorientiert und zweitens leistungs- oder qualitätsorientiert [Kai10]. Für den Entwurf eines Thread-Schedulers sind diese Kategorien allerdings zweitrangig. Die Auswahl einer Scheduling-Strategie kommt einer Gratwanderung gleich [Ola12] und ist stets ein Kompromiss [Hel]. Da es nicht möglich ist, einen idealen Scheduler zu erstellen, der nach allen Kriterien optimiert [Bra03], muss für den speziellen Algorithmus der Anwendungsfall die zu optimierenden Kriterien bestimmen. Nach Tanenbaum werden drei Einsatzgebiete gegeneinander abgegrenzt: der Echtzeitbetrieb, Interaktive Systeme (Dialogsysteme) und Stapel- bzw. Batchverarbeitung [Tan02]. Die daraus folgenden Ziele sind Allgemein: Fairness, Einhaltung von Systemregeln, Balance (gleichmäßige Auslastung aller Systemkomponenten) Echtzeit: Vorhersagbarkeit, Einhaltung von Deadlines Interaktive Systeme: Antwortzeit, Proportionalität (Erfüllung der Erwartung des Benutzers) Stapelverarbeitung: Effizienz, Durchsatz, Verweilzeit Ähnlich den verwendeten Systemen können auch die auf ihnen laufenden Threads charakterisiert werden. Threads bestehen typischerweise aus CPU-intensiven (CPUburst) und I/O-intensiven Phasen (I/O-burst). Dabei wird traditionell zwischen rechenintensiven Jobs (CPU-bound), die besonders den Prozessor belasten, und I/O-intensiven 8
Grundlagen Jobs (I/O-bound) unterschieden [New]. Ähnliche Threads behindern sich dabei gegenseitig, während Threads verschiedener Art das Gesamtsystem besser auslasten können. Ein Scheduler hat noch weitere Eigenschaften. Zunächst ist er entweder unterbrechend (präemptiv), dann wird er dem aktuell laufenden Thread den Prozessor nach einer bestimmten Zeit wegnehmen, um andere Threads arbeiten zu lassen, oder er ist kooperativ (bzw. nicht präemptiv). Dabei laufen Threads bis sie beendet sind, blockieren oder von selbst ihre Rechenzeit abgeben in Java mittels der Methode yield(). Als nächstes ist ein Scheduling-Algorithmus deterministisch, wenn die Informationsbasis, über welche entschieden wird, feststeht und damit eine Optimierungslösung berechenbar ist. Propabilistische Scheduler arbeiten mit Wahrscheinlichkeiten. Informationen über Anzahl, Ankunftszeit, I/O-Verhalten etc. sind nicht oder nur durch ihre Wahrscheinlichkeitsverteilung bekannt. Hier werden Heuristiken verwendet, um den Overhead klein zu halten [Kre04]. Weiterhin werden Scheduler danach unterteilt, zu welcher Laufzeit sie entscheiden [Sta09]. Offline-Algorithmen planen alle Aufgaben für die gesamte Lebenszeit vor dem Start des Systems. Daher benötigen sie sämtliche Informationen im Voraus, sind also deterministisch. Vorteile dieser Variante sind die Vorhersagbarkeit und der geringe Overhead, denn der Dispatcher braucht lediglich das nächste Element einer Tabelle oder Liste laden. Dagegen muss im Vorfeld ein sehr hoher Aufwand betrieben werden. Auch sind offline-scheduler unflexibel und in den allermeisten Systemen nicht anwendbar [Foh05]. Verbreiteter sind daher online-scheduler. Sie sind im Gegensatz zu zeitgetriggerten offline-varianten meist ereignisgetriggert. Informationen können dabei zur Laufzeit bekannt werden, erfordern dann aber großen Verarbeitungsoverhead. Deswegen sind die meisten online-scheduler propabilistisch und benutzen simple Heuristiken. Wichtig in Bezug auf Scheduling allgemein ist die Frage, wann der Algorithmus bzw. Dispatcher aktiviert wird. Gehen wir von online-scheduling aus, so ist die Antwort darauf eng damit verbunden, ob der Scheduler unterbrechend ist oder nicht [Hel06]. Im nicht präemptiven Fall geschieht die Aktivierung ereignisgetriggert, sobald der aktuell laufende Thread blockiert, terminiert oder sich freiwillig schlafen legt. In präemptiven Systemen können Threads verdrängt werden. Dies passiert, wenn beispielsweise seine Zeitscheibe abgelaufen ist, sich Prioritäten ändern, beim Auftreten von Interrupts oder wenn favorisierte Threads in den Zustand ready übergehen. Alternativ zu der Unterteilung nach Unterbrechbarkeit kann auch zwischen Zeit- und Ereignissteuerung unterschieden werden [Kai10]. 9
Grundlagen 2.2.2 Klassische Scheduling-Strategien Es existieren einige bekannte und weit verbreitete Strategien, die noch für Einkernprozessoren entwickelt wurden und dort die meisten Anwendungsfälle [Hel] bedienen. Auch die aktuelle Version von SHAP implementiert mit Round-Robin [Zab11] eine dieser klassischen Strategien. Die meisten modernen, komplexeren Algorithmen beruhen in irgendeiner Art auf ihnen, weshalb sie im Folgenden vorgestellt werden sollen. Die einfachste aller Strategien ist First In First Out (FIFO), auch als First Come First Serve (FCFS) bekannt. Alle Threads werden nach ihrer Ankunftszeit bzw. Wartezeit abgearbeitet und dabei nicht unterbrochen, sodass der Overhead minimiert wird. Typischerweise wird dies durch eine Warteschlange realisiert. FIFO wird häufig nur in stapelverarbeitenden Systemen verwendet, da hohe Antwortzeiten und geringer I/O-Durchsatz auftreten können, wenn Threads mit kurzen CPU-Bursts auf solche mit langen Bursts folgen. Dieses, als Konvoi-Effekt bekannte Verhalten, ist für interaktive und Echtzeit-Systeme ineffizient. Effizient kann das Verfahren sein, wenn vor allem langlebige Threads kooperativ programmiert werden, sich also freiwillig schlafen legen. Davon kann im Allgemeinen aber nicht ausgegangen werden. Ein vorhersagebasiertes Verfahren, das die Antwortzeit minimiert, ist Shortest Job First (SJF), auch als Shortest Process First (SPN) oder Shortest Processing Time (SPT) bekannt. Diese Strategie ist nicht unterbrechend. Wie ihr Name sagt, wird der kürzeste Thread ausgeführt, der bereit ist. Dazu müssen die Laufzeiten der Threads allerdings bekannt sein, was nur selten der Fall ist. Teilweise wird versucht über das vergangene CPU-Burst-Verhalten zu approximieren [Esp11]. Wird dieser Algorithmus unterbrechend implementiert, so wird er als Shortest Remaining Time First (SRTF) bezeichnet und ist durch das ständige Abgleichen recht aufwendig. Das große Defizit dieser Verfahren ist die Benachteiligung langer Threads, die sogar deren Verhungern möglich macht. Highest Response Ratio Next (HRRN) beruht ebenfalls auf Vorhersage, lässt im Gegensatz zu den zwei oben genannten Strategien gleichwohl langlebige Threads nicht verhungern. Durch sogenanntes Aging wird die Priorität eines Threads mit der Zeit erhöht. Dazu wird lediglich das Verhältnis von Wartezeit zu Bedienzeit gebildet die sogenannte response ratio. HRRN ist folglich nicht präemptiv und sollte bei kooperativ programmierter Software verwendet werden. Da die response ratio kurzer Threads mit der Zeit stärker wächst, werden diese immer noch bevorzugt. Der älteste, (meist verwendete [Esp11],) einfachste und fairste Algorithmus [Irr12] ist das zeitscheibenbasierte Round-Robin (RR). Dabei werden alle Threads in einer Warteschlange gehalten, aus der je der erste Thread für eine 10