Verfahren zur Bestimmung der Worst Case Execution Time (WCET)

Transkript

1 Hauptseminar Ausgewählte Kapitel eingebetteter Systeme Lehrstuhl 4 Betriebssysteme und Verteilte Systeme Andreas Kaiser Verfahren zur Bestimmung der Worst Case Execution Time (WCET) Inhaltsverzeichnis: 1. Einleitung 2. Methoden zur Bestimmung der WCET 2.1. Messung 2.2. Programmflussanalyse Aufbau eines Kontrollflussgraphen Architektur Pfadanalyse Ganzzahlige Programmierung Zusammenfassung 3. WCET Analyse bei portierbarem Code (Java) 4. Ausblick 1. Einleitung Bei Echtzeitanwendungen hängt die Korrektheit nicht nur vom logischen Ereignis ab, sondern auch vom Zeitpunkt, wann das Ereignis geliefert wird. [1] Das heisst das Ergebnis muss nicht nur korrekt sein, sondern auch rechtzeitig zur Verfügung stehen. Echtzeitsysteme tragen z.b. Anwendung in Fahr- und Flugzeugsteuerungen sowie Kraftwerken. Wenn hier die durch WCET Analyse gewonnene Ausführungszeit einen zu niedrigen Wert geliefert hat und eine Anwendung somit ihre Deadline verpassen kann dies zu katastrophalen Folgen führen. Die geschätzte WCET darf also nie kleiner als die tatsächliche WCET sein. Wird die WCET aber zu hoch abgeschätzt führt dies zu Ineffizienz im Echtzeitsystem: Entweder bleibt Rechenzeit ungenutzt oder die Anwendungen können gar nicht erst ausgeführt werden da sie von der Planbarkeitsanalyse abgelehnt werden. (siehe [2]) 1

2 2. Methoden zur Bestimmung der WCET 2.1 Messung Um die WCET durch Messung zu bestimmen zu können müssen alle Inputwerte beim Test betrachtet werden. Durch adaptive Messmethoden, bei denen bereits Restriktionen für die Inputwerte beim Test beachtet werden, lässt sich die Anzahl der zu beachtenden Inputwerte reduzieren, da nicht alle Eingaben in der Praxis vorkommen. Aus Zeitgründen ist es meistens jedoch nicht machbar alle möglichen Inputwerte zu testen. Ist das aber doch der Fall, gibt es dennoch die Möglichkeit dass die WCET zu klein abgeschätzt wird, da extrem seltene Inputkombinationen, welche aber gerade zu einer längeren Ausführungsdauer führen, schwer durch Messungen zu finden sind (Abb. 1). Die WCET kann folglich nicht oder nur schlecht durch Messungen bestimmt werden, obwohl dies in der Praxis oftmals Anwendung findet. Warscheinlichkeit BCET WCET Schwer bestimmbare Spitze am Rand Ausführungszeit fehlerhaft unsicher sicher Geschätzte WCET Abb Programmflussanalyse Aufbau eines Kontrollflussgraphen Als einfachen Ansatz zur Bestimmung der WCET könnte man die Instruktionen zählen und mit ihrer Ausführungsdauer multiplizieren. Hier werden jedoch Schleifen, Verzweigungen und weitere kontrollflussverändernde Elemente vernachlässigt. Aus diesem Grund werden Pfadanalyseverfahren eingesetzt. Das Programm wird zuerst in Grundblöcke zerteilt. Grundblockanfänge sind der erste Befehl, Ziele von Sprüngen sowie Befehle, die direkt auf Sprünge folgen (in Maschinencode in höheren Sprachen äquivalent). Ein Grundblock besteht aus dem Grundblockanfang und geht bis exklusive dem nächsten Grundblockanfang. Aus den Grundblöcken wird ein Kontrollflussgraph aufgebaut, wobei jeder Grundblock einen Knoten im Graphen darstellt und Kanten aufeinanderfolgende Grundblöcke verbinden. (Abb. 2 aus [2]) 2

3 Abb Architektur Nun muss für jeden Grundblock seine maximale Ausführungszeit bestimmt werden. Dies ist leider kein triviales Unterfangen, da meistens heuristische Bausteine wie Caches oder Pipelines, die die Ausführungsgeschwindigkeit des Programmes in häufig vorkommenden Situationen erhöhen sollen benutzt werden. Um starke Überschätzungen der Laufzeit zu vermeiden, muss die WCET-Analyse das Verhalten dieser Bausteine mitberücksichtigen [4]. Die besten Ergebnisse bekommt man folglich wenn das Programm hardwarenah als Maschinenprogramm analysiert wird. Nach [3] gibt es 2 Methoden die WCET von Grundblöcken mit Hinblick auf die Architektur zu bestimmen: Instruction-Timing- Addition (ITA) Innerhalb eines Grundblocks werden die Ausführungszeiten der einzelnen Instruktionen in Tabellen ausgelesen und addiert. Path-Segment-Simulation (PSS) Der Grundblock wird durch ein zyklengenaues Prozessormodell simuliert. Caches Das Verhalten von Programm-/Datenchaches hängt von der Reihenfolge des Befehlsholens bzw. des Datenzugriffs ab. Deshalb ist ITA nicht geeignet und PSS sollte benutzt werden. Ein sicherer Ansatz bei Datencaches ist z.b. dass ein Cache-Hit nur angenommen wird sofern dieser sicher ist, ansonsten ein Cache-Miss. Befehlscaches können mithilfe von CacheKonfliktgraphen modelliert werden. Mehr zu Konfliktgraphen ist unter [6] und zur CacheAnalyse unter [7] zu finden. Pipelining Ohne Befehlspipeline müssen die Ausführungszeiten einfach addiert werden um die gesamte Ausführungszeit zu bekommen. Mit Pipelining hängt die Anzahl der benötigten Zeit von der Tiefe der Pipeline und die Effektivität von der Länge der Pipeline ab (Abb. 3). Deshalb reicht es manchmal nicht aus Pipelining nur auf einzelnen Grundblöcken zu betrachten sondern auf ganzen Pfadsegmenten, da PSS sonst an Genauigkeit verliert. ITA ist ungeeignet Pipelingeffekte vorherzusagen, weswegen hier wie bei Caches PSS das Mittel der Wahl ist. 3

4 Zeit Pipeline stufen 10 Zeit 6 Pipeline stufen (a) ohne Pipelining (b) mit Pipelining Abb. 3 Superskalare Architekturen Bei superskalaren Architekturen können mehrere Grundblöcke gleichzeitig ausgeführt werden. Der Effekt ist ähnlich wie bei Pipelining wo die verschiedenen Pipelinestufen parallel ausgeführt werden. Ebenso ist hier PSS genauer für längere simulierte Segmente und ITA ungeeignet superskalare Architekturen überhaupt zu darzustellen Pfadanalyse Da nun die Ausführungszeiten der einzelnen Grundblöcke bekannt sind muss nun der zeitlich betrachtet längste Pfad durch das Programm gefunden werden. Dazu müssen alle möglichen Pfade durch das Programm geprüft werden. Hierbei reicht es die ausführbaren Programmpfade zu untersuchen und falsche Programmpfade, welche unter Berücksichtigung der Eingabebedingungen unmöglich sind, auszulassen. Zum Beispiel kann in dem Programmstück aus Abb. 2 Block B5 maximal einmal ausgeführt werden. Die meisten Probleme bereiten hier Schleifen, welche zu einer unendlichen Anzahl potenzieller Programmpfade führen können. Auch wenn alle Schleifen beschränkt sind, führen verschachtelte Schleifen und rekursive Programmaufrufe immer noch zu Problemen bei der Pfadanalyse. Bei der Lösung dieser werden unterschiedliche Methoden verfolgt um die automatische Abschätzung der möglichen Programmpfade zu verbessern: Die einfachste ist Schleifen zu beschränken und Rekursionen sowie Sprungbefehle zu verbieten. Jedoch ist dies meistens keine Alternative da die Programmierer dadurch sehr eingeschränkt werden. Ein weiterer Ansatz verwendet analyseunterstützend vom Programmierer angegebene funktionale Beschränkungen, wie nur exklusiv mögliche Ausführung verschiedener Blöcke oder Schleifenbegrenzungen. Der Nachteil dieser Methode ist, dass normalerweise keine Compiler vorhanden sind die diese Informationen aus dem Quellcode herauslesen und verarbeiten können. Infolgedessen ist der dritte Ansatz ein logischer Schluss aus dem vorhergehenden. Der Programmierer stellt die Informationen zum Programmfluss in einer eigenen Beschreibungssprache dar. 4

5 2.2.4 Ganzzahlige Lineare Programmierung (ILP) Anstatt in einem langwierigen Prozess die Ausführungszeiten aller Programmpfade und das Maximum derer zu ermitteln, können Methoden der Ganzzahligen Programmierung eingesetzt werden. Für jede Programmverzweigung wird eine Integer Variable angegeben, die bestimmt wie oft ein bestimmter Codeteil ausgeführt wird [5]. Diese Variablen werden herangezogen um Flussgleichungen, also strukturelle Beschränkungen, aufzustellen. Die Summe der eingehenden Kanten in einen Grundblock muss gleich der Summe der ausgehenden Kanten eines Grundblockes sein (Abb. 4 aus [2]). Zusätzlich werden die im letzten Punkt beschriebenen funktionalen Beschränkungen herangezogen um weitere Nebenbedingungen zu stellen. Diese können sich logisch aus dem Programmkontext ergeben, wie hier die Beschränkung x5 <= 1, da B5 maximal einmal durchlaufen werden kann, oder aber sie werden vom Programmierer vorgegeben. In diesem Falle zum Beispiel x3 <= 10 * x1, da der Programmierer angegeben hat, dass k positiv oder 0 ist (Abb. 1). Abb. 4 So wird aus einem ersten Ansatz WCET = Σ ci * xi ein komplexes ILP mit strukturellen und funktionalen Beschränkungen: WCET = max{ Σ ci * xi d1 = 1 Λ Σ dj = Σ dk = xi, i = 1 N Λ funktionale Beschränkungen} ci : Ausführungszeit des Grundblockes Bi xi : Maximale Anzahl der Ausführungen von Bi N : Anzahl der Grundblöcke d j : Eingehende Kanten d k :Ausgehende Kanten 5

6 2.3 Zusammenfassung: Die oben vorgestellte Kombination aus Pfadanalyse, Architekturmodellierung und ILP ist geeignet gute Vorhersagen über die WCET von Programmen/Programmpfaden zu treffen. Es werden hier die Vorteile aller Verfahren zusammengeführt. Durch die Pfad- und Programmflussanalyse werden strukturelle Beschränkungen des Codes gefunden und durch die Modellierung einzelner Grundblöcke bzw. Segmente und die dadurch gewonnene Hardwarenähe lassen sich die Ausführungszeiten dieser sehr gut analysieren. Diese Informationen werden dann benutzt um das Gesamtproblem der Berechnung der WCET des gesamten betrachteten Programmes mit einem Integer-Linear-Program Solver zu lösen. 3. WCET Analyse bei portierbarem Code (Java) Will man eine WCET Analyse auf portierbarem, also hardwareunabhängem, Code durchführen, unterliegt man folglich der Einschränkung dass die unterliegende Hardware nicht simuliert werden kann, da nicht bekannt ist auf welcher Hardware der Code später ausgeführt wird. Im folgenden wird WCET Analyse bei portierbarem Java Code untersucht. Hierbei ist als erstes anzumerken dass eine Just- in-time compiler (JIT) Implementierung der Virtual Machine (VM) ungeeignet ist, um darauf eine WCET-Analyse durchzuführen, da zur WCET die Worst-Case Zeit zur Kompilierung des Codes addiert werden muss, welche oft schwer vorhersehbar ist. Zur Unterstützung der Pfadanalyse wird eine WCETAn Klasse bereitgestellt [8][9], mit der z.b. Schleifengrenzen oder max. Blockausführungsanzahl angegeben werden können. Zur Berechnung der Ausführungszeiten der Grundböcke kann ein ITA ähnliches Verfahren herangezogen werden. Hierfür muss für jede Java Byte Code (JBC) Instruktion die WCET bereitgestellt werden. Hierbei existieren bedingt durch die VM 2 Probleme: Erstens gibt es Instruktionen welche je nach Kontext in dem sie aufgerufen werden unterschiedliche Ausführungszeiten haben. Hierbei sind der Zugriff auf multidimensionale Arrays oder Instruktionen die von der Klassenhierarchie ihres Aufrufs abhängen zu nennen. Diese Problem wird gelöst, indem die Ausführungszeit als Funktion T(n) = a + bn beschrieben wird, wobei a die normale Ausführungszeit ist und n die Anzahl der notwendigen zusätzlichen Iterationen(z.B. Anzahl der Dimensionen eines Arrays) mit den Kosten b. Zweitens gibt es Instruktionen die den Code zeitlich unvorhersehbar machen wie z.b. der Aufruf virtueller Methoden. Diese Instruktionen müssen entweder verboten oder es muss sichergestellt werden, z.b. durch Prefetching, dass diese Instruktionen doch eine vorhersehbare Ausführungszeit haben. In [8] werden noch Verfahren beschrieben mit denen versucht wird Pipelining Mechansimen zu simulieren sowie ein Ansatz, über Worst-case execution frequency vectors die WCET zu berechnen wenn die WCET der einzelnen JBC Instruktionen unbekannt ist 6

7 4. Ausblick Zu den hier beschriebenen Problemstellungen gibt es noch weitere, wie die Behandlung von Branch Prediction oder WCET Analyse bei Netzwerkanwendungen. Zusätzlich kommt hinzu dass CPUs immer komplexer werden und es dadurch schwieriger wird effiziente Modelle zu entwickeln. Gleichzeitig geht der Trend der Hersteller dazu über für ihre Prozessoren nur vereinfachte oder ungenaue Beschreibungen bereitzustellen [5]. Eine wünschenswerte Entwicklung wäre, wenn zukünftige Compiler (wie in erwähnt) die Unterstützung bieten würden Flussinformationen zu liefern. Der momentane Fortschritt in der WCET Analyse befindet sich bei Erstellung von ToolPrototypen für bestimmte Programmiersprachen und Prozessoren. Auf dem Markt sind auch schon einige Produkte verfügbar. Literatur: [1] Christian Ferdinand, Daniel Kästner u.a.., AbsInt Angewandte Informatik GmbH, Validierung des Echtzeitverhaltens von kritischer Echtzeit-Software [2] Jürgen Teich, FAU Erlangen/Nürnberg, Skript Hardware/Software Codesign, 2004 [3] W. Ye, R. Ernst, TU Braunschweig, Laufzeitanalyse für eingebettete Programme basierend auf der Programm- und Architekturklassifikation [4] Henrik Theiling, rw4.cs.uni-sb.de/~theiling/ publ/2003_doktor_theiling-eabs-de.html, 2003 [5] Andreas Heigl, TU Wien, Worst-Case Execution-Time Analyse [6] Jürgen Teich, FAU Erlangen/Nürnberg, Digitale Hardware/Software Systeme, Springer Verlag, 1997 [7] Christian Ferdinand, Universität des Saarlandes, Cache Behavior Prediction for RealTime Systems, 1997 [8] I. Bate, P. Puschner, u.a., University of York, TU Wien, Low-Level Analysis of a Portable Java Byte Code WCET Analysis Framework [9] G. Bernat, A.Burns, A. Wellings, Portable worst case execution time analysis using java byte code,