Vorlesung Echtzeitsysteme II

Transkript

1 1 / 51 Vorlesung Echtzeitsysteme II Thema 6: Worst-Case Execution Timing (WCET) Robert Baumgartl 24. November 2015

2 2 / 51 Literatur keine dedizierten Lehrbücher, da junges Gebiet Überblick über Forschungsstand: Reinhard Wilhelm et al. The Worst-Case Execution Time Problem Overview of Methods and Survey of Tools. In: ACM Transactions on Embedded Computing Systems 7.3 (Mai 2007), S Andreas Ermedahl. A Modular Tool Architecture for Worst-Case Execution Time Analysis. Diss. Uppsala Universitet, Juni 2003, Kapitel 2-4

3 Motivation 3 / 51 Problemstellung: Zur Festlegung einer Deadline muß die Abarbeitungszeit des zugehörigen Programmes bekannt sein. Wie kann man diese ermitteln? Im Zusammenhang mit Deadlines interessiert im wesentlichen die maximale Ausführungszeit (Worst Case Execution Time WCET) eines Programmes auf einer gegebenen Zielhardware. WCET ist variabel Schranke, Schätzwerte

4 Veranschaulichung 1 Fig. 1. Basic notions concerning timing analysis of systems. The lower curve represents a subset of measured executions. Its minimum and maximum are the minimal observed execution times and maximal observed execution times, resp. The darker curve, an envelope of the former, represents the times of all executions. Its minimum and maximum are the best-case and worst-case execution times, resp., abbreviated BCET and WCET. 1 Reinhard Wilhelm et al. The Worst-Case Execution Time Problem Overview of Methods and Survey of Tools. In: ACM Transactions on Embedded Computing Systems 7.3 (Mai 2007), S / 51

5 5 / 51 WCET-Ermittlung Der für das Scheduling genutzte Schätzwert der WCET muß 2 Bedingungen erfüllen (vgl. vorige Abbildung): 1. Er darf nie kleiner sein als die wahre WCET (ansonsten wird irgendwann die zugeordnete Deadline verletzt). 2. Er sollte nahe an der wahren WCET liegen (ansonsten wird Verarbeitungszeit verschenkt Verteuerung des Systems). Bemerkungen: relativ junger Zweig der Echtzeitsysteme Komplexitätsproblem: entweder ziemlich ungenau oder sehr aufwendig angetrieben durch Prozessorevolution

6 Statische vs. dynamische Analyse 6 / 51 Statische WCET-Analyse Ableitung der Abarbeitungszeit aus Programmcode, ohne dass dieser ausgeführt wird. benötigt Wissen über: Kontrollfluss des zu analysierenden Programms interne Zustände des Prozessors Dynamische WCET-Analyse (Messung) Instrumentierung des Codes repräsentative Menge an Eingabedaten Ausführung des Codes auf realer Hardware oder im Simulator Messung einer hinreichend großen Anzahl Programmabläufe Maximum aller Ausführungszeiten ist eine Abschätzung der WCET, jedoch keine sichere Schranke

7 7 / 51 2 Ebenen 1. makroskopische Betrachtung: Was macht ein gegebenes Programm? 2. mikroskopische Betrachtung: Was passiert im Prozessor Beide Ebenen sind nicht getrennt voneinander zu betrachten, sondern greifen ineinander.

8 Phasen der Statischen WCET-Analyse 8 / Analyse des Kontrollflusses formale Repräsentation des Programmes Ermittlung möglicher konkreter Abarbeitungspfade aus dem Quellprogramm und/oder ausführbarem Maschinencode 2. Verhaltensanalyse der zugrundeliegenden Prozessorarchitektur Einbeziehung von Kontextinformationen timingrelevanter Komponenten: Speicher, Caches, Pipelines, Sprungvorhersage erfordert präzises Modell des Prozessors 3. Errechnung einer Abschätzung für die WCET kombiniert Ergebnisse der beiden vorangegangenen Phasen

9 9 / 51 Control Flow Graph (CFG) repräsentiert den Steuerfluss eines (Teil-)Programms alle möglichen Pfade durch das Programm abgebildet Knoten sind so genannte Basic Blocks, die keine Verzweigungen enthalten ( einfaches, konstantes Timing) aus Quelltext oder Binärabbild erzeugbar Def. Ein Control Flow Graph (CFG) ist ein gerichteter Graph G = (V, E, i), bei dem die Knoten v V Basic Blocks repräsentieren. Eine Kante e E V V zwischen zwei Knoten v i, v j existiert genau dann, wenn v j unmittelbar nach v i ausgeführt wird. Es gibt genau einen Startknoten i V, dieser hat keine zu ihm führende Kante ( v V : (v, i) E).

10 Control Flow Graph Beispiel int foo(int x, int y) { int i = 0, ret=29; 3 A start } while (i<100) { /* A */ if (x == 42) { /* B */ ret = ret + 12; /* C */ } else { ret = 24; /* D */ } if (y%2 == 0) { /* E */ ret *= 23; /* F */ } else { ret += 95; /* G */ } i++; /* H */ } return ret; C 7 F 8 B 5 4 E 6 5 H 2 exit D G CFG mit zeitbewerteten Basic Blocks 10 / 51

11 11 / 51 3 Methoden der WCET-Ermittlung 1. baumbasierte Ermittlung (Timing Schema) 2. pfadbasierte Ermittlung 3. IPET-basierte Ermittlung (Implicit Path Enumeration Technique)

12 Variante 1: baumbasierte Ermittlung Grundidee 2 : Programm besteht grundsätzlich aus 3 verschiedenen Strukturen sequentielle Blöcke (seq) Verzweigungen (if ) Schleifen (loop) Aufbau eines Syntaxbaums für das Programm Annotation aller Schleifen mit maximaler Iterationszahl (maxiter) nach Bottom-Up Transformation der Strukturen des Syntaxbaums durch einfachere Strukturen 2 Chang Yun Park und Alan C. Shaw. Experiments with a Program Timing Tool Based on Source-Level Timing Schema. In: IEEE Computer 24.5 (Mai 1991), S / 51

13 13 / 51 Variante 1: baumbasierte Ermittlung Regeln für die Transformation T(S i ) sei die WCET für den sequentiellen Block S i 2 aufeinanderfolgende sequentielle Blöcke: T(seq(S 1, S 2 )) = T(S 1 ) + T(S 2 ) (Zeiten werden addiert) Verzweigung: T(if(S 1 ) then (S 2 ) else (S 3 )) = T(S 1 ) + max(t(s 2 ), T(S 3 )) (der längere der beiden Pfade dominiert die WCET) Schleife (S 1 ist der Schleifenkopf, S 2 der Schleifenkörper): T(while(S 1, S 2, maxiter)) = T(S 1 ) + (T(S 1 ) + T(S 2 )) maxiter

14 14 / 51 Variante 1: baumbasierte Ermittlung Syntaxbaum des Beispiels int foo(int x, int y) { int i = 0, ret=29; } while (i<100) { /* A */ if (x == 42) { /* B */ ret = ret + 12; /* C */ } else { ret = 24; /* D */ } if (y%2 == 0) { /* E */ ret *= 23; /* F */ } else { ret += 95; /* G */ } i++; /* H */ } return ret; while A seq if seq B C D if H E F G Syntaxbaum zu foo()

15 15 / 51 Variante 1: baumbasierte Ermittlung Schrittweise Transformation des Beispiels... an der Tafel...

16 16 / 51 baumbasierte Ermittlung Zusammenfassung Vorteile: einfache Methode geringer Aufwand skaliert ausgezeichnet mit Größe des Programms Nachteile: Korrelationen zwischen nicht-lokalen Codeteilen nicht berücksichtigt so genannte infeasible paths nicht ausschließbar

17 17 / 51 Nichtrealisierbare Pfade (Infeasible Paths) int baz(int x) { if (x<5) /* A */ x += 1; /* B */ else x *= 2; /* C */ if (x>10) /* D */ x=sqrt(x); /* E */ return x; /* F */ } Pfad <A, B, D, E, F> ist unmöglich, da wenn eingangs x < 5 gilt, die Bedingung D nicht wahr werden kann Wenn eingangs x > 10 gälte, wäre der einzig mögliche Pfad <A, C, D, E, F> Einbeziehung solchen Wissens kann Anzahl zu betrachtender Pfade drastisch reduzieren

18 18 / 51 Explizite Flussinformationen (Flow Facts) Beispiel int foo(unsigned int x) { char i=0; // A while(i < 100) { // B if ((i<20) (x<30)) // C x = x + 1; // D else x = x * 2; // E i++; // F if (errorcheck(i,x)) // G return 0; // H } return x; // I } Extrahierbare Flussinformationen: Bei jedem Aufruf von foo() kann die Schleife höchstens 100mal durchlaufen werden. Während der ersten 20 Iterationen kann E nicht ausgeführt werden. D kann nur während der ersten 30 Iterationen ausgeführt werden. Sobald x 30 gilt, muss für alle verbleibenden Iterationen E ausgeführt werden.

19 Problem: Obergrenzen für Schleifeniterationen 19 / 51 leicht: for (c=0; c<42; c++) { /* Tu wat */ } mittelschwer: int c; for (c=1; c < 100; c = c * 3 + 1) { /* do something */ } schwer (Euklidischer Algorithmus): unsigned long gcd_euclid(unsigned long a, unsigned long b) { unsigned long h; } while (b!= 0) { h = a % b; a = b; b = h; } return a;

20 Obergrenzen für Schleifeniterationen geschachtelte Schleifen? typisch: manuelle Annotationen (aufwändig, öde, fehleranfällig) automatische Schrankenextraktion ist Forschungsgegenstand 3 3 vgl. z. B. Jens Knoop, Laura Kovács und Jakob Zwirchmayr. Symbolic Loop Bound Computation for WCET Analysis. In: Proceedings of the 8th international conference on Perspectives of System Informatics (PSI 11). 2011, S / 51

21 21 / 51 Variante 2: pfadbasierte Ermittlung Grundidee: Suche nach dem längsten Pfad durch den CFG ist dieser realisierbar, dann handelt es sich um dem Pfad der WCET falls nicht, Suche nach zweitlängstem Pfad usw. Anmerkungen: Pfade werden explizit behandelt exponentielle Komplexität (Verschachtelungstiefe!) eignet sich gut für nichtverschachtelte Schleifen hardwarebedingte Eigenheiten auf dem Pfad können gut berücksichtigt werden

22 22 / 51 Variante 2: pfadbasierte Ermittlung Beispiel... an der Tafel...

23 Variante 3: Implicit Path Enumeration Technique Grundidee: jeder Basic Block i erhält eine (Worst-Case-)Ausführungszeit t i und einen Zähler x i, der angibt, wie häufig der Block aufgerufen wird aus dem Code und dem CFG werden (automatisiert oder manuell) logische bzw. algebraische Nebenbedingungen extrahiert, die das konkrete Abarbeitungsverhalten beschreiben (Maximalzahl Aufrufe, Schleifenobergrenzen usw.) Optimierungsproblem; es wird t i x i maximiert Ergebnis ist die WCET des betrachteten Codes i 23 / 51

24 24 / 51 Variante 3: Implicit Path Enumeration Technique Beispiel x start x starta start x HA Start- und Exitbedingungen: x start = 1, x exit = 1 x Aexit 3 A x A 5 B x B x BC 7 C x C 4 D x D x CE x EF 6 E x E 8 F x F 5 G x G x FH 2 H x H x exit x AB xbd x DE xeg x GH exit CFG mit Flussbedingungen Strukturelle Bedingungen: x start = x starta x A = x starta + x HA = x Aexit + x AB x B = x AB = x BC + x BD x C = x BC = x CE x D = x BD = x DE x E = x CE + x DE = x EF + x EG x F = x EF = x FH x G = x EG = x GH x H = x FH + x GH = x HA Schleifenschranke: x A 100 Zu optimierender Ausdruck: WCET = max(3x A + 5x B + 7x C + 4x D + 6x E + 8x F + 5x G + 2x H )

25 IPET Anmerkungen: typisch ist der Einsatz von Werkzeugen zur Lösung des Optimierungsproblems: Constraint Solvers Integer Linear Programming (ILP) 4 Pfade werden nicht explizit behandelt (Name!) komplexes Verhalten der zugrundeliegenden Hardware i. a. gut integrierbar (Caches, Pipelines) 4 besonders verbreitet, da leistungsfähige Open-Source-Software zur Verfügung steht vgl / 51

26 Mikroskopische Ebene 26 / 51 bisherige Betrachtung geht von der Voraussetzung aus, dass Blöcke und Maschineninstruktionen eines Programmes voneinander weitestgehend unabhängig sind Dies ist in modernen Prozessoren (meist) nicht der Fall! Einbeziehung der Einheiten nötig, die das Timing der Instruktionen beeinflussen: Caches Pipeline Sprungvorhersage Out-of-Order-Execution? Superskalarität (mehrere Einheiten auf dem Core) Branch Prediction und Speculative Execution (MMU Virtueller Speicher)

27 Processorcaches Motivation Prozessoren werden schneller schneller als der Hauptspeicher : Abbildung: Geschwindigkeitszuwachs von Prozessor und Hauptspeicher, bezogen auf John L. Hennessy und David A. Patterson. Computer Architecture. A Quantitative Approach. 4. Aufl. Elsevier, 27 / 51

28 Prozessorcaches Motivation Beobachtung: zeitliche und räumliche Lokalität von Zugriffen auf den Hauptspeicher (90/10-Regel). Idee: Bei Referenz eines Datums im Hauptspeicher wird der das Datum enthaltende Speicherblock in einen kleinen, sehr schnellen Zwischenspeicher übertragen, so dass Referenzen auf weitere Daten, die in der Nähe liegen, dann aus dem Cache bedient werden können. Abbildung: Beispiel einer einfachen Speicherhierarchie 7 7 John L. Hennessy und David A. Patterson. Computer Architecture. A Quantitative Approach. 4. Aufl. Elsevier, 2007, S / 51

29 Prozessorcaches Funktionsprinzip Zugriffsoperation mindestens Faktor 10 schneller als gecachtes Medium Cache-Hit vs. Cache-Miss Assoziativität: Anzahl Positionen, an denen eine Line gespeichert werden kann genau 1 Möglichkeit: direct-mapped n verschiedene Möglichkeiten: n-wege-assoziativ (n {2, 4, 8, 16}) überall: vollassoziativer Cache virtuell vs. physisch indexierter Cache inklusive (Intel) vs. exklusive (AMD) Speicherung Eigenschaften sind ggf. experimentell bestimmbar 8. 8 Tobias John und Robert Baumgartl. Exact Cache Characterization by Experimental Parameter Extraction. In: Proceedings of the 15th International Conference on Real-Time and Network Systems (RTNS 07). Nancy, März 2007, S / 51

30 Timingbeispiele t l [Zyklen] Pentium 4 Opteron 240 Itanium 2 ARM SA1110 L L HS 36 (?) Tabelle: Latenzen älterer Cachearchitekturen 9 ) Aktuelles Beispiel 10 : Intel Core i7 Xeon 5500 L1 Cache hit: 4 cycles L2 Cache hit: 10 cycles L3 Cache hit: 40/65/ cycles (unshared/shared/remote) Local RAM: 60 ns (180 3GHz) Remote RAM: 100 ns (300 3 GHz) 9 Kamen Yotov, Keshav Pingali und Paul Stodghill. X-Ray: A Tool for Automatic Measurement of Hardware Parameters. In: Proceedings of the Second International Conference on the Quantitative Evaluation of Systems (QEST 2005). 2005, S siehe auch 30 / 51

31 31 / 51 Prozessorcache Leseoperation Ablauf: 1. CPU referenziert ein Datum X mit der virtuellen Adresse A lesend 2. (MMU setzt virtuelle in physische Adresse um) 3. Cache Lookup: Durchmustern des Caches nach A gefunden (Cache Hit): X wird an CPU übertragen nicht gefunden (Cache Miss): X wird aus Hauptspeicher geholt Verzögerung (Miss Penalty), gleichzeitiges Laden der entsprechenden Line in den Cache. Falls kein Platz mehr im Cache Auswahl einer zu verdrängenden Cache-Line, Verdrängung dieser, um Platz zu schaffen.

32 32 / 51 Prozessorcache Schreiboperation 1. CPU referenziert ein Datum X mit der virtuellen Adresse A schreibend 2. Cache Lookup: Durchmustern des Caches nach A Cache Hit 2 Möglichkeiten: Write-Through: X wird im Cache aktualisiert und zusätzlich in den Hauptspeicher geschrieben ( durch den Cache ) Write-Back: X wird nur im Cache aktualisiert; erst wenn die zugehörige Line verdrängt wird, wird diese in den Hauptspeicher übertragen Cache Miss 2 Möglichkeiten: Write-Allocate: Datum wird im Hauptspeicher aktualisiert und zugehörige Line wird in den Cache übertragen Write-No-Allocate: Datum wird nur im Hauptspeicher aktualisiert

33 33 / 51 Prozessorcache Verdrängung von Cachelines ideal: Verdrängung der Cacheline, die zukünftig am längsten nicht benötigt wird (unmöglich) First In First Out (FIFO; aka Round Robin ) Motivation: die älteste Line wird stets verdrängt leicht zu implementieren z. B. Motorola MPC 56x, Intel XScale, ARM 9, ARM 11 Least Recently Used (LRU) Motivation: die Line, die am längsten nicht genutzt wurde, wird verdrängt (zu) komplexe Logik z. B. Intel Pentium, MIPS 24K/34K

34 34 / 51 Prozessorcache Verdrängung von Cachelines Pseudo Least-Recently Used (PLRU) Motivation: Approximation von LRU mit deutlich niedrigerem Aufwand z. B. Intel Pentium II-4, Power PC 75x Most Recently Used (MRU) Motivation: noch simplere Approximation von LRU 1 Bit/Line nötig z. B. Intel-Nehalem-Architektur (bestimmte Xeon, i5, i7)

35 Pseudo Least-Recently Used (PLRU) Approximation von LRU mittels binärer Bäume bei n-wege-assoziativität pro Set n 1 Tree-Bits benötigt; Bedeutung: 0 = linker Subbaum 1 = rechter Subbaum Tree-Bits zeigen stets zum potentiell zu ersetzenden Element nach jedem Hit werden alle Bits, die auf das betreffende Element verweisen, invertiert Beispiel 11 für eine PLRU-Referenzfolge (4 Wege, Referenz e, a, f ): e M 1 1 a H 1 1 f M 1 0 a b c d a b e d a b e d a b e f Initial state: After a miss to e: After a hit to a: After a miss to f: [a, b, c, d] [110] [a, b, e, d] [011] [a, b, e, d] [111] [a, b, e, f] [010] 11 Daniel Grund und Jan Reineke. Toward Precise PLRU Cache Analysis. In: Proceedings of the 10th International Workshop on Worst-Case Execution Time Analysis (WCET 2010). Hrsg. von Björn Lisper. Brussels, Juli 2010, S / 51

36 Most Recently Used (MRU) 36 / 51 manchmal PLRU (sic!) oder Bit-based PLRU genannt approximiert LRU mit minimalem Aufwand pro Line 1 Bit; Bedeutung: 0 = längere Zeit nicht referenziert 1 = kürzlich referenziert bei Cache Hit wird das zugehörige Bit stets auf 1 gesetzt Ausnahme: wenn der Hit die letzte verbliebene 0 auf 1 setzen würde, dann werden alle Bits auf 0 gesetzt, nur das Bit des Hits auf 1 ( Global Flip ) bei Cache Miss: Ersetzung der ersten Line, deren Bit 0 ist Bit der neu eingelagerten Line wird 1

37 Most Recently Used (MRU) Beispiel Beispiel 12 für eine MRU-Referenzfolge (4 Wege): initialer Zustand: [F, G, T, H] Referenzfolge O, F, H 1 F 1 F 1 F 0 F 0 G O 1 O F 1 O H 0 O 1 T 1 T 1 T 0 T 0 H 0 H 0 H 1 H 12 nach Nan Guan, Mingsong Lv und Wang Yi. WCET Analysis with MRU Caches: Challenging LRU for Predictability. In: Proceedings of the 18th Real-Time and Embedded Technology and Applications Symposium (RTAS 12). Beijing, Apr. 2012, S / 51

38 Least-Recently Used (LRU) 38 / 51 relativ gut untersucht für den Einsatz in Echtzeitsystemen Beispiel: 4-Wege-assoziativer Cache F G T H X X F G T Alter der Lines F G T H T T F G H Alter der Lines H wird ersetzt. Cache Miss Cache Hit

39 39 / 51 Analyse von LRU Literaturhinweis / Quellennachweis: Jan Reineke. Caches in WCET Analysis. Diss. Universität des Saarlandes, Nov Christian Ferdinand, Florian Martin und Reinhard Wilhelm. Applying Compiler Techniques to Cache Behavior Prediction Vortragsfolien Sebastian Altmeyer, Uni Saarbrücken Vorlesungsfolien Peter Puschner,

40 40 / 51 Analyse von LRU Must- and May-Analysis Problem, den konkreten Cacheinhalt für einen bestimmten Abarbeitungspfad im CFG zu ermitteln ist unentscheidbar stattdessen Nutzung Abstrakter Interpretation, um bestimmte Eigenschaften eines Caches für einen Ausführungspfad zu bestimmen (Verlust an Information, aber effizient berechenbar!) Hier: 1. Ermittlung oberer Grenzen für das Alter von Speicherblöcken im Cache (Must-Analysis) 2. Ermittlung unterer Grenzen für das Alter von Speicherblöcken im Cache (May-Analysis)

41 41 / 51 Must-Analysis für LRU-Caches Idee: Ermittlung oberer Grenzen (og) für das Alter von Speicherblöcken nach bestimmten Regeln og Assoziativität Block ist im Cache {F} max-age 0 F ist gerade referenziert worden {G} {T,X} 1 2 {} 3 Beispiel eines abstrakten Cachezustandes (4-Wege) G hat ein max. Alter von 1 (gerade referenziert worden oder im Takt davor) T und X haben beide ein max. Alter von 2 (referenziert während der letzten beiden Takte oder gerade)

42 42 / 51 Must-Analysis für LRU-Cache Abstrakte Update-Funktion Regeln: 1. Wenn der Speicherblock x referenziert wird, dann wird max-age(x) = 0 gesetzt. 2. Für alle anderen Lines c des Caches gilt: wenn max-age(c) max-age(x), dann max-age(c) = max-age(c) wenn max-age(c) < max-age(x), dann max-age(c) = max-age(c) + 1 Beispiel: X referenziert {F} {X} {G} {F} {T,X} {T,G} {} {} Alter der Lines

43 43 / 51 Must-Analysis für LRU-Cache Join: Kombination mehrerer Steuerflüsse an bestimmten Stellen im CFG vereinigen sich Steuerflüsse (Ende von Alternativen) zwei differierende abstrakte Cachezustände müssen konservativ zu einem vereinigt werden Es wird der Mengendurchschnitt beider abstrakter Cachezustände unter Beachtung des maximalen Alters gebildet. Beispiel: {F} {T} {} {G} {T,X} JOIN {G} {F} = {G} {T,F} {} {X} {X}

44 Beispiel für Must-Analysis eines LRU-Caches start [{}, {}, {}, {} ] [ {D}, {}, {A}, {} ] [ {A}, {}, {}, {} ] A [ {D}, {}, {A}, {} ] [ {}, {}, {}, {} ] = [ {}, {}, {}, {} ] [ {A}, {}, {}, {} ] B C D [ {B}, {A}, {}, {} ] [ {C}, {A}, {}, {} ] = [ {}, {A}, {}, {} ] [ {D}, {}, {A}, {} ] exit 44 / 51

45 45 / 51 Beispiel für Must-Analysis eines LRU-Caches Schlussfolgerungen / Ergebnis kein einziger Cache Hit prognostiziert, obwohl Schleife Hits verursachen müsste Ursache: erste Iteration generiert nur Misses (zu konservativ abgeschätzt) Abhilfe: erste Iteration aufrollen und getrennt analysieren (Virtual Loop Unrolling)

46 Aufrollen der ersten Schleifeniteration start [{}, {}, {}, {} ] [ {}, {}, {}, {} ] [ ] {A}, {}, {}, {} B exit [ ] {}, {A}, {D}, {} [ ] {A}, {D}, {}, {} B A D A D C [ {A}, {}, {}, {} ] [ {B}, {A}, {}, {} ] [ {C}, {A}, {}, {} ] = [ {}, {A}, {}, {} ] [ {D}, {}, {A}, {} ] C [ {A}, {D}, {}, {} ] [ {B}, {A}, {D}, {} ] [ {C}, {A}, {D}, {} ] = [ {}, {A}, {D}, {} ] Ergebnis: Referenzen zu A und D werden nach der ersten Iteration korrekt als Hit klassifiziert Für Referenzen zu B und C sind keine Aussagen möglich (als Miss anzunehmen) [ {D}, {}, {A}, {} ] exit 46 / 51

47 47 / 51 May-Analysis für LRU-Cache funktioniert ähnlich wie Must-Analysis ermittelt jedoch Untergrenzen (ug) für das Alter von Speicherblocks im Cache ug Assoziativität Block ist garantiert nicht im Cache

48 48 / 51 Analyse von Caches Fazit Nutzung Abstrakter Interpretation (Must- und May-Analysis) reduziert Rechenaufwand und verliert Information, erlaubt dadurch aber Aussagen über garantierte Cache-Hits und Cache-Misses LRU besonders einfach zu analysieren; andere Ersetzungsstrategien leider nicht

49 Alternativen zur Cacheanalyse 49 / 51 Einschränkungen des Programmiermodells keine Rekursion erlaubt Schleifen nur mit konstanter Iterationsanzahl Beeinflussung des Caches Abschalten inakzeptabler Leistungseinbruch, aber deterministisches Timing Einfrieren (Cache Freeze) Cache Coloring Ersetzung des Caches durch Scratch-Pad Memory direkt adressiert, gleiche Zugriffsgeschwindigkeit wie Cache häufig genutzte Datenstrukturen in SPM Compilerunterstützung nötig

50 50 / 51 Cache Coloring Problem: Cacheinhalte interferieren zwischen mehreren Tasks und dem Betriebssystem (Thrashing!) Idee: Partitionierung des Hauptspeichers, so dass einzelne Cache-Lines jeweils einer Task exklusiv zur Verfügung stehen Thrashing unmöglich Nachteil: Cache muss im gleichen Verhältnis wie der Hauptspeicher zugeteilt werden (d.h., wenn eine Task 50% des Caches erhält, erhält sie automatisch auch die Hälfte des Adressraums) Literatur: Jochen Liedtke, Hermann Härtig und Michael Hohmuth. OS-Controlled Cache Predictability for Real-Time Systems. In: Proceedings of the Third IEEE Real-Time Technology and Applications Symposium (RTAS 97). Juni 1997, S ISBN:

51 Schluss 51 / 51 Was haben wir nicht behandelt?... konkrete Programmiermodelle, synchrone Sprachen, viele Aspekte des Scheduling (z. B. Flexible Computations), verteilte Echtzeitsysteme, Software Engineering für zuverlässige und echtzeitfähige Systeme (Real-Time UML), Verifikation mit Spin und Promela, echtzeitfähige Speicherverwaltung (RT-GC), Echtzeit-Protokolle für das Internet, NTP...