Analyse des Einﬂusses der Zeitscheibenlange beim ...ls12- · PDF fileDiplomarbeit Analyse des Einﬂusses der Zeitscheibenlange beim¨ RoundRobin-Scheduling in Cache- und Scratchpad-basierten

Diplomarbeit

Analyse des Einflusses derZeitscheibenlange beim

RoundRobin-Scheduling inCache- und Scratchpad-

basierten Systemen

Sebastian Hanloh

Technische Universitat DortmundFakultat fur Informatik

Lehrstuhl Informatik XII

10. November 2008

Gutachter:

Prof. Dr. Peter MarwedelDipl. Inf. Olivera Jovanovic

INHALTSVERZEICHNIS I

Inhaltsverzeichnis

1 Einleitung 11.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.2 Ziele der Diplomarbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.3 Aufbau der Diplomarbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2 Grundlagen 52.1 Zielarchitektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.1.1 ARM7-Prozessorfamilie . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.1.2 Speicherarchitekturen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.1.3 MPARM-Simulator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.1.4 Energiemodell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.2 Eingebettete Betriebssysteme . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.3 Scheduling-Algorithmen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192.4 Optimierungs-Algorithmen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

2.4.1 Integer Linear Programming . . . . . . . . . . . . . . . . . . . . . . . . 222.4.2 Bergsteigeralgorithmus . . . . . . . . . . . . . . . . . . . . . . . . . . . 222.4.3 Simulated Annealing . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

2.5 Pareto-Optimum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242.6 Verwandte Arbeiten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3 SPM-Allokations-Strategien fur mehrere Prozesse 273.1 Statische Allokation fur mehrere Prozesse (SAMP) . . . . . . . . . . . . . . . . 283.2 Dynamische Allokation fur mehrere Prozesse (DAMP) . . . . . . . . . . . . . . 293.3 Hybride Allokation fur mehrere Prozesse (HAMP) . . . . . . . . . . . . . . . . . 30

4 Theoretische Betrachtung des Multiprozesssystems 354.1 Einfluss der Zeitscheibenlange auf das Multiprozesssystem . . . . . . . . . . . 36

4.1.1 Einfluss der Zeitscheibenlange auf Multiprozesssysteme mit Cache . . . 394.1.2 Einfluss der Zeitscheibenlange auf Multiprozesssysteme mit SPM . . . . 40

4.2 Optimierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424.3 Laufzeitmodell fur ein RoundRobin-Schedule . . . . . . . . . . . . . . . . . . . 45

5 Arbeitsablauf und Implementierung 495.1 Uberblick uber den Arbeitsablauf . . . . . . . . . . . . . . . . . . . . . . . . . . 49

5.1.1 profitAnnotator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 515.1.2 outputGenerator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 515.1.3 ILP-Generatoren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 525.1.4 addressGenerator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 525.1.5 cplex2header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 545.1.6 RTEMS Erweiterung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 565.1.7 XAMPopt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

II INHALTSVERZEICHNIS

5.2 Optimierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 655.2.1 Bergsteigeralgorithmus . . . . . . . . . . . . . . . . . . . . . . . . . . . 665.2.2 Simulated Annealing . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

6 Ergebnisse 716.1 Beschreibung der Benchmarks . . . . . . . . . . . . . . . . . . . . . . . . . . . 726.2 Verhalten Scratchpad-basierter Systeme bei unterschiedlichen Zeitscheiben-

langen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 736.2.1 Industrial Benchmark . . . . . . . . . . . . . . . . . . . . . . . . . . . . 736.2.2 Mobile Device Benchmark . . . . . . . . . . . . . . . . . . . . . . . . . 756.2.3 Telecommunication-DSP Benchmark . . . . . . . . . . . . . . . . . . . . 776.2.4 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

6.3 Einfluss des Overheads auf die SPM-Allokations-Strategien DAMP und HAMP . 806.3.1 Industrial Benchmark . . . . . . . . . . . . . . . . . . . . . . . . . . . . 806.3.2 Mobile Device Benchmark . . . . . . . . . . . . . . . . . . . . . . . . . 816.3.3 Telecommunication-DSP Benchmark . . . . . . . . . . . . . . . . . . . . 826.3.4 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

6.4 Verhalten Cache-basierter Systeme bei unterschiedlichen Zeitscheibenlangen . 846.4.1 Industrial Benchmark . . . . . . . . . . . . . . . . . . . . . . . . . . . . 846.4.2 Mobile Device Benchmark . . . . . . . . . . . . . . . . . . . . . . . . . 876.4.3 Telecommunication-DSP Benchmark . . . . . . . . . . . . . . . . . . . . 896.4.4 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

6.5 Vergleich von Cache- und Scratchpad-basierten Systemen bei unterschiedli-chen Zeitscheibenlangen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

6.6 Analyse der iterativen Optimierung im Arbeitsablauf . . . . . . . . . . . . . . . 956.7 Optimierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

6.7.1 Industrial Benchmark . . . . . . . . . . . . . . . . . . . . . . . . . . . . 966.7.2 Mobile Device Benchmark . . . . . . . . . . . . . . . . . . . . . . . . . 976.7.3 Telecommunication-DSP Benchmark . . . . . . . . . . . . . . . . . . . . 986.7.4 WCET Optimierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 996.7.5 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

7 Zusammenfassung und Ausblick 101

Abbildungsverzeichnis 103

Tabellenverzeichnis 107

Literaturverzeichnis 109

1 Einleitung 1

Kapitel 1

Einleitung

”The most profound technologies are those that disappear. They weave themselves into the

fabric of everyday life until they are indistinguishable from it.“ Dieses Zitat von Mark Weiser aus

seinem Aufsatz ”The Computer for the 21st Century“ [Wei91] aus dem Jahr 1991 beschrieb

schon vor 17 Jahren sehr gut, was moderne eingebettete Systeme ausmachen und wohin die

Entwicklung der Informationstechnologie in den letzten drei Jahrzehnten gefuhrt hat.

Anfang der 80er Jahre mussten sich noch mehrere Personen die Rechenkraft eines Main-

frame Computers teilen. Mit der Einfuhrung des Personal Computers in den 90er Jahren,

stand jeder Person ein eigener Rechner zur Verfugung. Der Trend in Richtung Miniaturisie-

rung ging weiter, so dass bereits heutzutage die Mehrheit der informationsverarbeitenden

Gerate kleine, portable, in großere Produkte integrierte Computer sind. Im 21. Jahrhundert

stehen somit jedem eine Vielzahl von informationsverarbeitenden Geraten, in den verschie-

densten Erscheinungsformen, zur Verfugung. So werden 79% aller High-End-Prozessoren fur

eingebettete Systeme verwendet [Mar06]. Der Weltmarkt fur elektronische Produkte umfasste

im Jahr 2006 ein Gesamtvolumen von $1,8 Billionen. Es wird erwartet, dass das Gesamtvolu-

men im Jahr 2012 auf $3,2 Billionen anwachsen wird [Spi07]. In Kombination mit einem Zitat

der Journalistin Mary Ryan unterstreicht dies die Bedeutung eingebetetter Systeme: ”... but

embedded chips form the backbone of the electronics driven world in which we live ... they

are part of almost everything that runs on electricity“ [Rya95].

Definiert sind eingebettete Systeme als informationsverarbeitende Systeme, die in großere

Produkte eingebettet und die normalerweise fur den Nutzer unsichtbar sind. Solche Produkte

konnen z.B. Mobiltelefone, Autos, industrielle Anlagen oder auch Hauser sein. Wichtige Merk-

male eingebetteter Systeme sind Reaktivitat, spezielle Benutzerschnittstellen, Zuverlassigkeit,

Effizienz und Echtzeitfahigkeit [Mar06].

2 1 Einleitung

1.1 Motivation

Effizienz, genauer Energieeffizienz und Laufzeiteffizienz, sowie Echtzeitfahigkeit sind die Merk-

male eingebetteter Systeme, welche in dieser Arbeit betrachtet werden.

Viele eingebettete Systeme sind mobile Systeme, die ihren Energiebedarf durch Batterien

bzw. Akkus befriedigen. Da Kunden, trotz steigender Anforderungen, lange Akkulaufzeiten

erwarten, muss diese knappe Ressource sehr effizient genutzt werden. Neben der Energie-

effizienz spielt auch die Laufzeiteffizienz eine wichtige Rolle, weil grundsatzlich ein Minimum

an Ressourcen fur die gewunschte Funktionalitat aufgebracht werden sollte. Dabei ist darauf

zu achten, alle Zeitschranken einzuhalten. Laufzeiteffizienz hat demnach auch Einfluss auf

das zweite, in dieser Arbeit betrachtete Merkmal, die Echtzeitfahigkeit. Hier stehen vor allem

die Worst-Case-Laufzeiten im Fokus des Interesses. Viele Systeme sind auf eine schnelle

durchschnittliche Laufzeit, der sog. Average-Case-Laufzeit, optimiert. Dies kann aber unter

Umstanden zu einer Katastrophe fuhren, wenn sicherheitsrelevante Systeme nicht in der not-

wendigen Zeitspanne reagieren. Oder anders ausgedruckt, wenn sie bestimmte harte Dead-

lines nicht einhalten [Mar06].

Um den steigenden Anforderungen gerecht zu werden und ein gewisses Maß an Flexibilitat

zu gewahrleisten, steigt der Einsatz von Software in eingebetteten Systemen stetig an. Ein

Gesetz von Moore besagt, dass sich die Codemenge im Bereich der Konsumelektronik al-

le zwei Jahre verdoppelt [VR98]. Wie im PC-Breich, ist es auch in eingebetteten Systemen

ublich, dass mehrere Softwareprozesse um die Hardwareresource CPU konkurrieren. Um

dieser steigenden Komplexitat Herr zu werden, werden vermehrt Betriebssysteme eingesetzt.

Diese Betriebssysteme erfullen bestimmte, fur ihren Einsatz zugeschnittene, Eigenschaften.

So mussen sie beispielsweise die Echtzeitfahigkeit eines Systems unterstutzen oder sie sind

stark konfigurierbar, so dass diese eingebetteten Betriebssysteme besonders wenig Speicher

in Anspruch nehmen und eine gute Laufzeiteffizienz aufweisen.

Um die Laufzeit- und Energieeffizienz komplexer eingebetteter Systeme weiter zu steigern,

werden Speicher mit einer sehr geringen Speicherkapazitat, aber dafur sehr kurzen Antwort-

zeiten, zwischen CPU und Hauptspeicher geschaltet. Die Notwendigkeit solcher Pufferspei-

cher ergibt sich auch durch den wachsenden Unterschied zwischen der CPU- und Haupt-

speichergeschwindigkeit. Die Geschwindigkeit von Speichern wachst nur um ungefahr das

1,07-fache pro Jahr, wohingegen die Prozessorgeschwindigkeit um das 1,5- bis 2- fache pro

Jahr steigt [Mac02]. Klassischerweise handelt es sich bei diesen Pufferspeichern um Ca-

ches. Caches haben jedoch die Nachteile, dass sie aufgrund der Evaluationshardware und

verschiedener Verwaltungsbits viel Chipflache, im Verhaltnis zur geringen Speicherkapazitat,

benotigen und eine schlechte Energieeffizienz aufweisen. Ebenso ist die Vorhersagbarkeit der

Antwortzeiten negativ anzumerken. Caches sind somit fur den Einsatz in eingebetteten Sys-

temen weniger gut geeignet. Als alternative Speicher bieten sich so genannte Scratchpads,

oder kurz SPMs, an. Hier werden hoch frequentierte Variablen und Instruktionen abgelegt. Die

Vorteile bestehen darin, dass keine Hardwareevaluation notwendig ist und auf Verwaltungsbits

verzichtet werden kann. Dadurch sinkt der Energiebedarf pro Speicherzugriff und die Einspa-

1.2 Ziele der Diplomarbeit 3

rung an Chipflache kann genutzt werden um die Speicherkapazitat des SPM zu erhohen. Da

der Inhalt dieses Pufferspeichers immer bekannt ist, ist eine sehr gute Vorhersagbarkeit der

Laufzeiten gegeben. Die Gute der Energieersparnis hangt dabei von der Analyse zur Compi-

lezeit ab.

1.2 Ziele der Diplomarbeit

RoundRobin-Scheduling ist einer der altesten, einfachsten und meist verwendeten Algorith-

men zur Realisierung eines Multiprozesssystems. In dieser Arbeit wird davon ausgegangen,

dass alle Prozesse zum Zeitpunkt t = 0 zur Ausfuhrung bereitstehen. Jedem Prozess wird ein

fester Zeitabschnitt zugewiesen, Quantum oder Zeitscheibe genannt, in dem er laufen darf.

Wenn ein Prozess nach Ablauf der Zeitscheibe noch aktiv ist, wird er unterbrochen und ein

anderer Prozess wird zur Ausfuhrung gebracht. Die Realsierung von RoundRobin ist sehr ein-

fach. Der Scheduler muss nur eine Queue mit allen aktiven Prozessen vorhalten. Abbildung

1.1 visualisiert eine solche Queue. Sobald Prozess P2 sein Quantum aufgebraucht hat, wird

er an das Ende der Queue eingereiht und der nachste Prozess, in diesem Beispiel ist das

der Prozess P3, zur Ausfuhrung gebracht. Die interessante Frage von RoundRobin betrifft die

Lange der Zeitscheibe. Der Wechsel zwischen den Prozessen kostet einen gewissen Zeitauf-

Abbildung 1.1: RoundRobin-Scheduling. (a) Queue aller aktiven Prozesse. (b) Queue aller aktivenProzesse nachdem P2 sein Quantum aufgebraucht hat.

wand, und somit auch einen gewissen Energieaufwand. So mussen bei jedem Wechsel, auch

als Kontextwechsel bezeichnet, bestimmte Register, Stack, Heap, usw. gesichert und geladen

werden. Angenommen dieser Verwaltungsaufwand dauert 1ms. Wenn die Zeitscheibe bei-

spielsweise 4ms lang ist, wurden 20% der CPU-Zeit nur fur den Kontextwechsel aufgebracht.

Um dieses Verhaltnis zu verbessern, konnte man die Zeitscheibenlange beispielsweise auf

1s setzen. Ausgehend von einem Multiprozesssystem mit vier Prozessen, wie es in Abbildung

1.1 dargestellt ist, wurde sich im schlimmsten Fall eine Zeitdauer von 3,004s ergeben, bis ein

Prozess auf externe Ereignisse reagieren kann. Diese Zeitspanne wird auch als Antwortzeit

bezeichnet. Eine derartige Antwortzeit ist fur die meisten Nutzer eindeutig zu lang. Zusam-

menfassend lasst sich festhalten, dass eine zu kurze Zeitscheibe viele Kontextwechsel zur

Folge hat und somit die Laufzeit- und Energieeffizienz negativ beeinflusst und eine zu lange

Zeitscheibe, lange Antwortzeiten fur interaktive Anfragen verursacht [Tan02].

In dieser Arbeit wird ein Multiprozesssystem mit einem RoundRobin-Schedule betrachtet. Es

werden Systeme, dessen Speicherhierarchie aus SPM und Hauptspeicher und Systeme, des-

4 1 Einleitung

sen Speicherhierachie aus Cache und Hauptspeicher bestehen, im Hinblick auf Energie- und

Laufzeitbedarf bei verschiedenen Zeitscheibenlangen analysiert und verglichen. Dabei wer-

den verschiedene SPM-Allokations-Strategien bzw. Cachekonfigurationen berucksichtigt. Im

Anschluss an die Analyse folgt eine Optimierung der Zeitscheibenlange.

RoundRobin ist vor allem wegen seiner einfachen und laufzeiteffizienten Realisierung fur ein-

gebettete Systeme interessant. Der Einsatz von RoundRobin wirkt sich außerdem positiv auf

die Analyse aus, da durch das periodische Auftreten der Kontextwechsel typische Eigenschaf-

ten der verschiedenen Systeme aufgezeigt werden.

1.3 Aufbau der Diplomarbeit

Das Kapitel 2 behandelt die, fur diese Arbeit notwendigen, Grundlagen. Es wird die Zielarchi-

tektur vorgestellt und einige interessante Ausblicke zum Thema ”Eingebettete Betriebssyste-

me“ gegeben. Dabei steht das Betriebssystem RTEMS besonders im Fokus des Interesses,

da dieses fur die Realisierung des Multiprozesssystems grundlegend ist. Abschließend wer-

den die wichtigsten Begriffe im Gebiet der Scheduling-Algorithmen und einige Optmierungs-

verfahren vorgestellt.

Die theoretischen Grundlagen fur die, im Rahmen dieser Arbeit implementierten SPM-Alloka-

tions-Strategien, werden in Kapitel 3 behandelt. Dabei findet eine Unterscheidung zwischen

einem statischen und einem dynamischen Ansatz statt. Eine dritte Allokations-Strategie kom-

biniert diese Ansatze.

Neben den Einschrankungen bezuglich der Antwortzeit und der Relation von Overhead zu

Zeitscheibenlange, wird fur die Zeitscheibenlangenoptimierung auch die Einhaltung der Dead-

lines der Prozesse, eine wichtige Rolle spielen. Auf die Wechselwirkungen zwischen diesen

Einschrankungen und der Zeitscheibenlange wird in Kapitel 4 genauer eingegangen und das

grundlegende Vorgehen der implementierten Optimierungs-Algorithmen hergeleitet.

Das Kapitel 5 beschreibt den Arbeitsablauf zur Realisierung der SPM-Allokations-Strategien.

Desweiteren werden die notwendigen Anpassungen der Zielarchitektur, um die Zeitschei-

benlange mit hinreichender Genauigkeit konfigurieren zu konnen, in diesem Kapitel motiviert

und erlautert. Den Abschluss des Kapitels 5 bildet der Abschnitt uber die Implementierung der

Optimierungs-Algorithmen. Zur Auswahl steht ein Algorithmus, welcher immer eine optimale

Zeitscheibenlange findet, falls eine solche existiert und eine laufzeiteffiziente Heuristik.

Die Analyse des Einflusses der Zeitscheibenlange auf Multiprozesssysteme mit unterschied-

lichen Konfigurationen, wird in Kapitel 6 durchgefuhrt. Neben durchschnittlichen Energie- und

Laufzeitwerten, werden auch interessante Konfigurationen hervorgehoben. Außerdem wird

die Optimierung beispielhaft auf die analysierten Benchmarks angewendet.

Das Kapitel 7 schließt diese Arbeit mit einem Fazit und einem Ausblick auf eine Fortfuhrung

einiger herausgearbeiteter Aspekte.

2 Grundlagen 5

Kapitel 2

Grundlagen

Die Realisierung des Multiprozesssystems wird auf Basis einer bestimmten Zielarchitektur

durchgefuhrt. Diese wird im Abschnitt 2.1 beschrieben. Der Abschnitt 2.2 geht auf eingebette-

te Betriebssysteme im Allgemeinen und RTEMS im Speziellen ein. Um die Hardwareresource

CPU fur mehrere Prozesse quasi-parallel nutzbar zu machen, bedarf es verschiedener Sche-

dulingalgorithmen. Die wichtigsten Begriffe in diesem Kontext, eine Klassifikation und ein kon-

kreter Algorithmus werden in Kapitel 2.3 vorgestellt.

Die verschiedenen SPM-Allokationsstrategien werden mit Hilfe von ganzzahliger Programmie-

rung verwirklicht. Das mathematische Konzept dazu wird im Abschnitt 2.4 beleuchtet. Außer-

dem wird hier eine theoretische Betrachtung der, fur die Optimierung verwendeten Algorith-

men durchgefuhrt, um im Anschluss in Abschnitt 2.5 auf Pareto-optimale Mengen einzugehen.

Den Abschluss dieses Kapitels bildet Abschnitt 2.6 mit einem Uberblick von Arbeiten, auf die

diese Arbeit aufbaut und die ahnliche Zielsetzungen oder Ansatze verfolgen.

2.1 Zielarchitektur

In diesem Abschnitt wird die Zielarchitektur, die Basis fur die Realisierung der SPM-Allo-

kationsstrategien, die Analyse und die Optimierung ist, vorgestellt. Sie besteht aus einem

ARM-Prozessor und einer Speicherhierachie. Da die zu optimierende Software nicht auf rea-

ler Hardware zur Ausfuhrung gebracht wird, sondern auf dem MPARM-Simulator, wird dieser

ebenfalls vorgestellt. Die zur Bestimmung des Energiebedarfes notwendigen Modelle, werden

abschließend beschrieben.

2.1.1 ARM7-Prozessorfamilie

Prozessoren aus der ARM-Familie sind, wegen ihrer kleinen Chipflache und ihrem sehr gu-

ten Verhaltnis von Energieverbrauch zu Rechenleistung, fur eingebettete Systeme von Be-

6 2 Grundlagen

Abbildung 2.1: Befehls-Pipeline des ARM7TDMI Prozessors

deutung. Dabei handelt es sich um RISC-Prozessoren. RISC steht fur ”Reduced Instruction

Set Computer“. Im Gegensatz zu CISC-Prozessoren ( ”Complex Instruction Set Computer“),

verfugen sie uber wesentlich vereinfachte Befehlsworte. Dies tragt zur Reduzierung des De-

kodierungsaufwandes und zu einer kurzen Interrupt-Reaktionszeit bei. Letzteres ist vor allem

fur Echtzeitsysteme relevant.

In dieser Arbeit wird ein ARM7TDMI Prozessor simuliert. Er nutzt eine dreistufige Pipeline,

bestehend aus der ”Instruction-Fetch“-, ”Decode“- und ”Execute“-Phase (Abbildung 2.1).

Der Speicherzugriff des ARM7TDMI-Prozessors erfolgt uber einen 32-Bit breiten Bus, auf dem

sowohl Daten als auch Adressen ubertragen werden. Die Daten konnen dabei Bytegroße (8-

Bit), Halbwortgroße (16-Bit) oder Wortgroße (32-Bit) aufweisen [ART04].

Der Prozessor verfugt uber zwei Befehlssatze. Zum Einen uber den 32-Bit ARM-Befehlssatz

und zum Anderen uber den 16-Bit Thumb-Befehlssatz. Im Vergleich zu einer 16-Bit Architek-

tur, verfugen 32-Bit Architekturen uber eine bessere Performance bei der Verarbeitung von

Daten. Außerdem lasst sich ein großerer Adressraum ansprechen. Dem gegenuber steht die

bis zu 30% hohere Codedichte von 16-Bit Architekturen. Diese hat positiven Einfluss auf den

Speicherdurchsatz. So verringert sich die Anzahl der Cache-Misses im Durchschnitt um ca.

30% beim Einsatz des Thumb-Befehlssatzes im Vergleich zum ARM-Befehlssatz [KG02].

Thumb-Befehle bilden eine Untermenge des ARM-Befehlssatzes, d.h. es gibt zu jedem 16-Bit

Befehl ein 32-Bit Aquivalent. Zur Laufzeit werden die Thumb-Befehle in ARM-Befehle, ohne

Leistungsverluste, umgesetzt. Die Konsequenz ist, dass der Thumb-Befehlssatz alle Vorteile,

wie ein 32-Bit Adressraum, die 32-Bit Register, den 32-Bit Datenbus und die 32-Bit ALU, des

ARM7TDMI-Prozessors nutzen kann [Sea01].

2.1.2 Speicherarchitekturen

Dieser Arbeit liegen zwei verschiedene Speicherhierarchien, siehe Abbildung 2.2, zugrunde.

Festplatten werden nicht betrachtet. Es wird hier die Annahme getroffen, dass die Speicher-

kapazitat des Hauptspeichers ausreicht, um den Speicherbedarf der Benchmarks zu befriedi-

gen. Wie in Kapitel 1.1 bereits erwahnt, werden verschiedene Speichertypen, aufgrund unter-

schiedlicher Eigenschaften, kombiniert. Im Folgenden werden die drei Speichertypen, Haupt-

speicher, Cache und SPM detaillierter vorgestellt. Zunachst wird die technische Realisierung

2.1 Zielarchitektur 7

ARM7

Cache

Hauptspeicher

ARM7

SPM

Hauptspeicher

(a) (b)

Abbildung 2.2: In dieser Arbeit betrachtete Speicherhierarchien. (a) Speicherhierachie mit Cache undHauptspeicher. (b) Speicherhierachie mit Scratchpad und Hauptspeicher.

und die grundlegende Organisation beschrieben, um im Anschluss auf die Energieeffizienz

und Antwortzeiten einzugehen.

2.1.2.1 Hauptspeicher

Hauptspeicher sind Speicherbausteine mit wahlfreiem Zugriff und werden durch DRAMs, ”Dy-

namic Random Access Memory“, realisiert. Dabei werden die einzelnen Bits mit Hilfe von

Kondensatoren gespeichert. Im rechten Teil der Abbildung 2.3 wird die technische Realisie-

rung einer Speicherzelle veranschaulicht [JNW08]. Durch den simplen Aufbau einer Spei-

cherzelle, lassen sich DRAMs sehr kostengunstig realisieren. Auch die geringe Chipflache im

Verhaltnis zur Speicherkapazitat ist positiv anzumerken. Da die Kondensatoren, aufgrund von

Leckstromen, ihre Spannung nicht uber einen unbegrenzten Zeitraum halten konnen, daher

auch der Zusatz ”Dynamic“, mussen die Speicherzellen in regelmaßigen Abstanden ausge-

lesenen und wieder beschrieben werden. Dies wird als Refreshzyklus bezeichnet. In dieser

Phase konnen keine Hauptspeicherzugriffe erfolgen. Der grundlegende Aufbau eines DRAM

wird im linken Teil der Abbildung 2.3 visualisiert. Jeder DRAM enthalt mehrere Zellenfelder

welche die Speicherzellen enthalten. Jede einzelne Speicherzelle speichert ein Bit. Eine ein-

deutige Adressierung wird uber die Spalten- und Zeilendecoder realisiert. Um das parallele

Auslesen mehrerer Bits, oder anders ausgedruckt, das Auslesen von Worten, zu ermoglichen,

werden eine bestimmte Anzahl der Zellenfelder zu einer Bank zusammengefasst. Wobei es

wiederum mehrere Banke innerhalb eines DRAM gibt.

Die grundlegende organisatorische Struktur eines Hauptspeichers besteht, wie in Abbildung

2.4(a) dargestellt, aus maximal 2n adressierbaren Worten [Sta00]. Jedes Wort hat eine ein-

deutige n-Bit Adresse.

Die Zugriffszeit von DRAMs liegt zwischen 80ns und 250ns. Sie ist abhangig von der Spei-

cherkapazitat und variiert u.a. wegen der, im Abstand von ca. 8ms, auftretenden Refreshzy-

klen. Je nach Einsatzgebiet, weisen DRAMs bis zu 16GB Speicherkapazitat auf [HP03]. Die

Versorgungsspannung liegt bei 1,5V [TeR07].

8 2 Grundlagen

DRAM

Input/Output& Puffer

Spalten Decoder

Zellenfeld

...Spalten...

...R

eihe

n...

Rei

hen

Dec

oder

Schreib-/Lese- Verstärker

.

Wortleitung

Bitleitung

Transistor

Kondensator

Speicher-zelle

Abbildung 2.3: Aufbau von DRAM und seiner Speicherzellen

2.1.2.2 Cache-Speicher

Caches sind, wie Hauptspeicher, Speicherbausteine mit wahlfreiem Zugriff. Sie werden durch

SRAMs, ”Static Random Access Memory“, realisiert. Durch die verschachtelte Schaltung

mehrerer Transistoren, wie in Abbildung 2.5 dargestellt, kommt es zu einer regenerativen

Ruckkopplung, die das Speichern eines Bits ermoglicht. Durch die Verwendung von Tran-

sistoren sind die Herstellungsprozesse dieses Speichertyps und die von Mikroprozessoren

identisch. Somit wird die Integration von SRAMs auf den Prozessordies wesentlich verein-

facht [JNW08]. Im Vergleich zur DRAM-Technologie, benotigen SRAMs fur die gleiche Spei-

cherkapazitat, mehr Chipflache. Positiv anzumerken ist das Entfallen von Refreshzyklen. Die

Adressierung erfolgt uber die Auswahl der ”Wordline“, in Abbildung 2.5 abgekurzt mit WL. Die

Zelle wird ausgelesen, indem die Spannungsdifferenz zwischen den ”Bitlines“, BL und BL,

bestimmt wird.

Abbildung 2.4 zeigt eine Cache-Hauptspeicher-Struktur. Um die Abbildung zwischen Haupt-

speicher und Cache zu vereinfachen, unterteilt man den Hauptspeicher in M = 2n/K gleich

große Blocke zu je K Worten. Der Cache besteht seinerseits aus C Zeilen zu je K Worten.

(a) (b)

BlockTag

Blocklänge(K Worte)

Block(K Worte)

012

012

2 -1n

Wortbreite

Zeilen-nummer

Speicher-adresse

Cache:Hauptspeicher:

Abbildung 2.4: Cache-Hauptspeicher-Struktur. (a) grundlegende Hauptspeicher-Struktur. (b) grundle-gende Cache-Struktur.


Da zu jedem Zeitpunkt nur ein Teil der Hauptspeicherblocke in den Cachezeilen gespeichert

werden kann, und somit keine eindeutige Abbildung der Blocke auf die Cachezeilen existiert,

enthalt sie einen Tag, der den jeweils gespeicherten Block eindeutig identifiziert. Hinzu kom-

men einige Verwaltungsbits. Zudem ist Evaluationshardware erforderlich, die die verschiede-

nen Ersetzungs- und Schreibstrategien realisiert. Caches unterscheiden sich in ihrer Assozia-

tivitat. Wenn eine Assoziativitat von 1 vorliegt, gibt es fur eine Hauptspeicheradresse genau

einen moglichen Cacheblock. Dies wird auch als ”Direct Mapping“ bezeichnet. Bei einem vol-

lassoziativen Cache, konnen die Daten einer Adresse in jedem Block untergebracht werden.

Neben ”Direct Mapping“ und Vollassoziativitat, gibt es 2-fach-, 4-fach-, 8-fach-, usw. assoziati-

ve Organisationen. Fur mehr Einzelheiten soll an dieser Stelle auf [HP03] verwiesen werden.

Die Zugriffszeit von SRAMs liegt zwischen 0,5ns und 25ns und die Speicherkapazitat kann

bis zu 16MB betragen [HP03]. In dieser Arbeit wird die Kapazitat zwischen 256B und 16kB

liegen. Die Versorgungsspannung betragt 0,7V [TeR07].

2.1.2.3 Scratchpad-Speicher

SPMs werden in der gleichen Speichertechnologie realisiert wie Caches, mit SRAMs. Wie in

der Einleitung bereits erwahnt, entfallt hier die Evaluationshardware. Auch aufwendige Struk-

turen entfallen, da die Allokation compilergesteuert ist. Allokationsstrategien fur Multiprozess-

systeme werden im Kapitel 3 detailliert beschrieben.

Abbildung 2.5: Aufbau einer SRAM-Speicherzelle

2.1.2.4 Performancevergleich

Die konstruktionsbedingte Große einer Speicherzelle wird als ein Vielfaches der Quadrat-

flache der kleinsten fertigbaren Strukturlange, ”minimum Featuresize“ (F2), angegeben. SRAM-

Zellen weisen eine Große von 140F2 auf. DRAM-Zellen lediglich eine Große von 6F2 [TeR07].

Daraus resultieren, fur DRAMs, wesentlich niedrigere Herstellungskosten pro Bit und eine

bessere Ausnutzung der Chipflache.

Der Energieverbrauch von CMOS-Schaltkreisen wird durch folgende Formel bestimmt [CSB92]:

P = α ∗CL ∗V 2dd ∗ f (2.1)

10 2 Grundlagen

Dabei steht α fur die Schaltaktivitat, CL fur die Lastkapazitat, Vdd fur die Versorgungsspannung

und f fur die Taktfrequenz. Die Versorgungsspannung geht also quadratisch in den Energie-

bedarf ein. Die, im Verhaltnis zu DRAMs, nur ca. halb so große Versorgungsspannung von

SRAMs, verringert den Energiebedarf somit um den Faktor 4,49. Die Schreibenergie pro Bit

von DRAMs, mit 5E-15 J/Bit (Refreshzyklen nicht beachtet), ist sogar fast um den Faktor 10

großer als bei SRAMs, mit 7E-16 J/Bit [TeR07]. Hier spielt neben der Versorgungsspannung

auch die Realisierungstechnologie und der Einsatz der Evaluationshardware eine Rolle.

Zudem hangt der Energieverbrauch von SRAMs und DRAMs von ihrer Speicherkapazitat ab.

Je großer diese ist, umso umfangreicher fallt die Verwaltungshardware, wie beispielsweise

Adressierungsdekoder, aus. Auch die langeren Leitungen haben einen negativen Einfluss

[Hil04].

Die Zugriffszeiten von SRAMs und DRAMs weichen ebenfalls um den Faktor 10 von einander

ab. Eine Speicheranfrage in einer Hierarchie mit Cachespeicher ist aber nicht automatisch

um den Faktor 10 schneller. Denn bei einem Cache-Miss, d.h. wenn sich das Speicherob-

jekt nicht im Cache befindet (Gegenteil: Cache-Hit), muss das benotigte Datum erst aus der

nachst hoheren Hierarchiestufe, in dieser Arbeit ist dies der Hauptspeicher, geholt werden.

In einem Worst-Case-Szenario, in dem jedes Speicherobjekt aus dem Hauptspeicher geholt

werden muss, hat der Einsatz von Caches sogar einen negativen Effekt auf das Laufzeitver-

halten. In einem System mit SPM sind Speicheranfragen in diesem Adressbereich immer um

den Faktor 10 schneller, da der Inhalt zu jedem Zeitpunkt bekannt ist.

2.1.3 MPARM-Simulator

Um aufwendige Messungen an realer Hardware zu vermeiden, wird die Bestimmung des

Energieverbrauches und des Laufzeitverhaltens simulativ, mit Hilfe des MPARM-Simulators,

durchgefuhrt. Dieser, in SystemC realisierte, Simulator wurde ursprunglich fur MPSoCs (Multi

Abbildung 2.6: MPARM Architektur

Processor Systems on a Chip) entwickelt [LAB+04]. Abbildung 2.6 veranschaulicht den Auf-

bau. MPARM besteht aus einer konfigurierbaren Anzahl an Prozessoren und deren privaten

Speichern. Zusatzlich kann gemeinsamer Speicher hinzugefugt werden. Vervollstandigt wird


das System durch einen Interrupt- und einen Semaphoren-Controller. Als Bussystem kann

AMBA AHB oder STBus ausgewahlt werden. Getaktet wird das gesamte System uber eine

globale SystemC-Uhr.

Es stehen verschiedene Befehlssatzsimulatoren, wie z.B. fur ARM7-, StrongARM-, PowerPC-

und MIPS- Prozessoren, zur Verfugung. Implementiert sind diese in C/C++. Fur diese Arbeit

Abbildung 2.7: SWARM Architektur mit SystemC-Wrapper

wird der GPL-lizensierte ARM7 Befehlssatzsimulator, kurz SWARM (”SoftwareARM“) [Dal00],

genutzt. Dieser ermoglicht die Simulation des ARM-Befehlssatzes. Thumb-Befehle werden

nicht unterstutzt. Um SWARM in der SystemC-Umgebung nutzen zu konnen, wird ein Wrapper

benotigt, wie in Abbildung 2.7 dargestellt. Die grundlegende Struktur gliedert sich in folgende

C++ -Klassen:

• CArmProc: Die Schnittstelle von Wrapper und Prozessor-Kern CArmCore wird durch

diese Klasse gebildet. Die Synchronisation zwischen Wrapper und CArmProc erfolgt

durch den Aufruf der Cycle-Funkion. Sie veranlasst einen Simulationsdurchlauf. Die

Synchronisation zwischen CArmProc und CArmCore erfolgt dabei auf die gleiche Art.

Außerdem werden UART-Controller, Interrupt-Controller, Timer, lokaler Bus, Cache und

SPM mit Hilfe des CArmProc zusammengefuhrt. Der Timer kann dazu genutzt wer-

den periodische Interrupts zu erzeugen. Cache und SPM konnen wahlweise aktiviert

bzw. deaktiviert werden. Als Speichergroßen fur den SPM lasst MPARM Werte zwi-

schen 256B und 16kB zu. Die maximale Große fur Caches betragt 1MB. Der Nutzer

hat die Wahl zwischen einem Unified-Cache oder getrenntem Daten- und Instruktions-

Cache. Ferner konnen verschiedene Assoziativitaten, angefangen von direct-mapped

uber 2fach- und bis hin zu 16fach- assoziativen Caches, gewahlt werden. Wenn der

Cache aktiviert ist, laufen grundsatzlich alle Hauptspeicherzugriffe uber diesen Puffer-

speicher.

Der Wrapper beinhaltet die Datenstruktur PINOUT. Sie dient der Kommunikation des

Prozessorkerns CArmCore mit der SystemC-Simulationsumgebung. Hieruber werden

12 2 Grundlagen

alle Steuerinformationen und Daten weitergeleitet.

Bei einem Hauptspeicherzugriff wird die Cycle-Funktion des CArmProc solange durch

den Wrapper nicht aufgerufen, bis die Transaktion abgeschlossen ist. Dadurch soll die

Synchronisation der einzelnen Komponenten sichergestellt werden.

• CArmCore: In dieser Klasse wird die Arbeitsweise eines ARM7TDMI-Prozessors so

genau wie moglich nachgebildet. Jeder Ausfuhrungszyklus wird durch den Aufruf der

Funktion Cycle ausgelost.

MPARM ist in der Lage, verschiedene Statistiken in unterschiedlichen Darstellungsformen

wahrend eines Simulationslaufes zu sammeln. Der Nutzer muss beim Aufruf festlegen, wel-

che Ausgaben erzeugt werden sollen. Neben einer Tracedatei, in der alle Prozessorzugriffe

protokolliert werden, kann auch eine Datei mit Verlaufen der Kommunikationssignale ausge-

geben werden. Die interessanteste Ausgabeform fur diese Arbeit ist jedoch die Statistikdatei.

Hier lassen sich das Laufzeitverhalten und der Energieverbrauch der Benchmarks ablesen.

Außerdem legt MPARM hier die Statistiken bezuglich der verschiedenen Speicher ab, wie

beispielsweise die Anzahl der Lese- und Schreibzugriffe oder die Caches-Hits und Cache-

Misses. Daten uber die Busaktivitaten, die ebenfalls in der Statistikdatei gesammelt werden,

sind vor allem fur Multiprozessorsysteme relevant und werden in dieser Arbeit nicht detaillier-

ter betrachtet.

2.1.4 Energiemodell

Den Energiebedarf des Gesamtsystems ermittelt MPARM, indem es wahrend des Simulati-

onslaufes den Energiebedarf der einzelnen Komponenten, ausgenommen Semaphoren- und

Interruptcontroller, bestimmt. Die Energieverbrauchswerte wurden von STMicroelectronics zur

Verfugung gestellt und basieren auf einer 0,13 µm Technologie.

Fur die ARM7-Prozessorkerne wird ein instruktionsbasiertes Energiemodell, wie es in [VT94]

vorgeschlagen wurde, angewendet. Dabei werden drei verschiedene Zustande berucksichtigt:

IDLE, RUNNING und STALLED. Ein Prozessor kann per Softwareinterrupt in den IDLE-Zu-

stand gebracht werden. Dieser zeichnet sich durch einen sehr geringen Energiebedarf aus.

Die Bestimmung des Energiebedarfes wird auf Basis des Zustandes STALLED durchgefuhrt,

wenn die Prozessorpipeline aufgrund von Daten- oder Instruktionsabhangigkeiten blockiert

wird. In allen anderen Fallen wird der RUNNING-Zustand angenommen.

Der Energieverbrauch fur Hauptspeicher, Cache und SPM wird nach einem analytischen Mo-

dell, das abgeleitet ist aus [CZG98], bestimmt. Es wird, auf Basis einer Wortgroße von 32 Bit,

neben der Art des Speicherzugriffes, lesend oder schreibend, auch die Große des Speichers

berucksichtigt. Fur Caches werden zudem, in Abhangigkeit von der Cache-Organisation, zu-

satzlich Kosten fur den Tag-Zugriff angerechnet [LPB04].

Das Energiemodell fur den Bus, basiert im Falle des AMBA AHB Busses auf [BCZZ04] und

im Falle des STBusses auf [BZZ04]. In beiden Modellen wird die Anzahl der Busteilnehmer

und die ubertragende Datenmenge berucksichtigt.

2.2 Eingebettete Betriebssysteme 13

2.2 Eingebettete Betriebssysteme

Um den Bedurfnissen moderner eingebetteter Systeme gerecht zu werden, steigt der Einsatz

von Betriebssystemen in diesem Bereich stetig an. Folgende Aspekte sind im Bereich der

eingebetteten Systeme von Bedeutung [MWV+04]:

• Konfigurierbarkeit: Aufgrund knapper Ressourcen ist es nicht moglich Betriebssyste-

me einzusetzen, welche samtliche Funktionen und Gerate unterstutzen. Es ist vielmehr

erforderlich, sie flexibel an verschiedene Anwendungsgebiete anpassen zu konnen.

• Treiber: Aufgrund des hohen Aufkommens von Spezialgeraten im Bereich der einge-

betteten Systeme, ist es nicht sinnvoll, verschiedenste Treiber im Kernel zu integrieren.

Man nutzt dafur spezielle Softwareprozesse.

• Schutzmechanismen: In der Regel werden nur getestete, im Vorhinein bekannte und

somit verlassliche Programme zur Ausfuhrung gebracht. Auf umfangreiche Schutzme-

chanismen, wie z.B. Speicherschutz, kann verzichtet werden.

• Interrupts: Im Bereich der Standardbetriebssysteme ist es ublich, dass Interrupts vom

Betriebssystem abgefangen werden. Dieser Verwaltungsoverhead kann, aufgrund der

Verlasslichkeit der Software, eingespart werden. So konnen Interrupts direkt Prozesse

starten oder stoppen.

• Echtzeitfahigkeit: Da eingebettete Systeme reaktive Systeme mit Echtzeitanforderun-

gen darstellen, mussen diese auch vom eingesetzten Betriebssystem erfullt werden. In

diesem Zusammenhang spricht man von Echtzeitbetriebssystemen, abgekurtz RTOS

(”Real Time Operating System“). Takada definiert sie wie folgt: ”A real time operating

system is an operating system that supports the construction of real-time systems.“

[Tak01]. Folgende Kriterien sind von einem RTOS zu erfullen:

– Voraussagbarkeit: Das zeitliche Verhalten des Betriebssystems muss vorhersag-

bar sein. Alle Funktionen mussen eine obere Schranke fur ihre Laufzeit garantie-

ren.

– Scheduling-Fahigkeit: Scheduling kann als eine Abbildung einer Menge von Pro-

zessen, im Kontext der Betriebssysteme auch Tasks genannnt, auf Intervalle von

Ausfuhrungszeiten, angesehen werden. RTOSs mussen in der Lage sein Schedu-

lingalgorithmen umzusetzen oder zumindest, im Falle der offline Algorithmen, die

benotigten Funktionen zum Starten, Unterbrechen (Kontextwechsel) und Stoppen

von Tasks zur Verfugung stellen. Dazu mehr im Abschnitt 2.3. Voraussetzung dafur

ist eine prazise interne Darstellung der Zeit mit entsprechender Auflosung.

– Schnelligkeit: Das Kriterium der Laufzeiteffizienz eingebetteter Systeme gilt, be-

sonders im Hinblick auf die Vorhersagbarkeit, auch fur RTOS. Das Betriebssystem

muss in der Lage sein, auch Anwendungen zu unterstutzen, dessen Deadlines

innerhalb von Bruchteilen einer Sekunde liegen.

14 2 Grundlagen

Es gibt bereits eine Reihe kommerzieller und frei verfugbarer Betriebssysteme fur eingebette-

te Systeme.

SymbianOS ist ein sehr bekanntes und verbreitetes Betriebssystem fur Mobiltelefone. Es lauft

nativ auf ARM-Prozessoren, der Kernel kann durch DLLs erweitert werden und verwendet

preemptives Multitasking (siehe Kapitel 2.3), Scratchpads werden unterstutzt und Energie-

sparmodie sind realisiert [Mer03]. Durch die ”Real Time Compatibility Layer“ (RTCL) werden

auch Echtzeitanwendungen wie GSM-, EDGE- oder UMTS-Protokolle, unterstutzt [Sal05].

Dennoch entspricht es nicht allen oben genannten Kriterien. SymbianOS ist vor allem fur

Smartphones entwickelt worden. Da in diesem Bereich Software von Drittanbietern zur An-

wendung kommt, kann auf Schutzmechanismen nicht verzichtet werden. Durch eine virtuelle

Speicherverwaltung wird ein Speicherschutz zwischen den Prozessen realisiert. Auch Inter-

rupts werden vom Betriebssystem abgefangen. So existiert beispielsweise eine ”Hardware

Abstractions Layer“, welche die Schnittstelle zwischen Soft- und Hardware bildet.

Ein weiteres Betriebssystem aus dem Bereich der eingebetteten Systeme ist VxWorks. Ein-

satzgebiete sind beispielsweise der Automotivebereich, Luft- und Raumfahrt, Anlagenbau

oder Medizintechnik. Dabei handelt es sich um ein RTOS, welches alle oben genannten Kri-

terien erfullt. So verfugt VxWorks uber einen preemptiven und prioritatsbasierten Scheduler,

mehr dazu im Kapitel 2.3, welcher ein deterministisches Echtzeitverhalten garantiert [WiR07].

Daruber hinaus wird dieses konfigurierbare RTOS modernsten Anwendungen gerecht, in-

dem beispielsweise auch Netzwerkprotokolle, wie HTTP oder MobileIP, hinzugefugt werden

konnen.

SymbianOS und VxWorks sind proprietare Betriebssysteme. Einen Vertreter aus dem Be-

reich der Open-Source-Echtzeitbetriebssysteme stellt RTEMS dar. Auch RTEMS erfullt alle

oben genannten Kriterien. Zudem existiert eine Portierung fur den MPARM-Simulator. Featu-

res wie das Hinzufugen von Benutzererweiterungen ohne das komplette Betriebssystem neu

zu compilieren und die Realisierung eines RoundRobin-Schedules machen es zu dem idealen

RTOS fur diese Arbeit. Im Folgenden wird es detailliert betrachtet.

RTEMS

RTEMS steht fur ”Real-Time Executive for Multiprocessor Systems“ und stellt im wesentlichen

die folgenden Features zur Verfugung [REC03].

• Multitasking Fahigkeiten

• Unterstutzung von homogenen und heterogenen Multiprozessorsystemen

• Ereignisgesteuertes, prioritatsbasiertes und preemptives Scheduling

• Rate-Monotonic-Scheduling

• Kommunikation zwischen und Synchronistation von Tasks


• Prioritatsvererbung

• Interruptmanagement

• Dynamische Speicherallokation

• Konfigurierbarkeit

Ein wichtiges Designziel von RTEMS war es, eine Brucke uber zwei kritische Schichten ty-

pischer Echtzeitsysteme zu schlagen. Wie im linken Teil der Abbildung 2.8 dargestellt ist,

dient RTEMS als Puffer zwischen der Hardware und der anwendungsspezifischen Software.

Viele der Hardwareabhangigkeiten konnen durch Low-Level-Geratetreiber abgefangen wer-

Abbildung 2.8: RTEMS Architektur

den. RTEMS stellt zudem einen Ein-/Ausgabe-Manager zur Verfugung, welcher ebenfalls ei-

ne einheitliche Schnittstelle fur die Software darstellt. Auf Basis dieser Architektur, konnen

wiederverwendbare Standardkomponenten entwickelt werden. Die Moglichkeit, direkt auf die

Zielhardware zuzugreifen, bleibt dabei erhalten.

Die Schnittstelle fur Applikationen wird durch verschiedene ”Resource Manager“, die unter-

schiedliche Funktionen, z.B. fur das Scheduling oder die Behandlung von Interrupts, umfas-

sen, gebildet. Der rechte Teil der Abbildung 2.8 zeigt die interne Struktur. Der Kernel stellt

die zentrale Komponente dar. Er enthalt die CPU-abhangigen Routinen. Die wichtigsten ”Re-

source Manager“ werden im Folgenden vorgestellt. Die komplette Dokumentation findet sich

in [REC03].

2.2.0.1 Clock Manager

Um Echtzeitanwendungen zu unterstutzen, ist die Darstellung von Zeit unerlasslich. In RTEMS

ist die Basiszeiteinheit ein Tick. In welchen Intervallen Ticks auftreten, hangt von der jewei-

ligen Anwendung ab und bestimmt, in welcher Granularitat RTEMS Zeitperioden erfassen

kann. Zeitspezifische Funktionen, wie Timeouts oder die Spezifikation der Zeitscheibenlange

16 2 Grundlagen

beim RoundRobin-Schedule, werden abhangig von einer bestimmten Anzahl an Ticks ge-

macht. So kann z.B. eine Zeitscheibe 10 Ticks lang sein. Wenn die Zeitspanne zwischen den

Ticks 10ns lang ist, ergibt dies eine Zeitscheibenlange von 100ns. Fur die periodischen Inter-

rupts sorgt, in dieser Arbeit, der SWARM-Timer (Abbildung 2.7).

2.2.0.2 Initialization Manager

Die Initialisierungsphase von RTEMS umfasst das Kreieren und Starten des Initialisierungs-

task sowie den Aufruf der nutzerdefinierten Geratetreiber. Im Initialisierungstask, wiederum,

werden die Anwendungstasks kreiert und gestartet. In Multiprozessorsystemen wird außer-

dem die Interprozessor-Kommunikationsschicht initialisiert.

2.2.0.3 Task Manager

Zur Realisierung eines Multiprozesssystems, in diesem Kontext auch als Multitaskingsystem

bezeichnet, werden grundlegende Funktionen zur Verwaltung der Tasks benotigt. Diese stellt

der Task Manager zur Verfugung. In RTEMS ist ein Task definiert als der kleinste ausfuhrbare

Thread, welcher um Systemressourcen konkurriert. Dabei wird jedem Task sein ”Task Control

Block“, kurz TCB, zugeordnet. Hier wird u.a. die Task-ID, der Task-Name, die aktuelle Prio-

ritat, der aktuelle Zustand, der Ausfuhrungsmodus und im Falle eines Kontextwechsels, der

Kontext des Tasks, abgelegt.

Die Prioritat eines Task druckt dessen Wichtigkeit in Relation zu den anderen Tasks aus.

RTEMS unterscheidet zwischen 255 Stufen. Dabei gilt, je geringer der Nominalwert, je wich-

tiger ist der Task.

Tasks konnen funf verschiedene Zustande annehmen:

• Ausfuhrend: Der Task wird aktuell ausgefuhrt.

• Bereit: Der Task ist bereit ausgefuhrt zu werden.

• Blockiert: Der Task kann nicht ausgefuhrt werden.

• Ruhend: Der Task ist kreiert, aber noch nicht gestartet worden.

• Nicht existent: Der Task wurde noch nicht kreiert oder wieder geloscht.

Der Zustandsautomat in Abbildung 2.9 verdeutlicht die moglichen Ubergange.

Task konnen zudem in unterschiedlichen Modi ausgefuhrt werden. Diese ergeben sich aus der

Kombination der folgenden Komponenten: Preemption, ASR-Verarbeitung, Interrupt-Stufe und

”Timeslicing“. Wenn ein Task als preemptiv gekennzeichnet ist, kann er von anderen Tasks


Abbildung 2.9: Zustande der Tasks in RTEMS

unterbrochen werden. Andernfalls ist es auch nicht durch Tasks hoherer Prioritat moglich,

diesen zu unterbrechen. ASR steht fur ”Asynchronous Signal Processing“. Diese Komponen-

te determiniert den Zeitpunkt, wann eingehende Signale durch den Task verarbeitet werden.

Die Interrupt-Stufe eines Task gibt an, welche Interrupts wahrend seiner Ausfuhrung aktiv

sein durfen. Wenn ”Timeslicing“ aktiviert ist, wird fur Tasks gleicher Prioritat das RoundRobin-

Schedule angewendet.

2.2.0.4 User Extensions Manager

RTEMS zeichnet sich durch einfache Erweiterbarkeit aus. Realisiert wird dies durch User Ex-

tensions. Dem Benutzer wird es ermoglicht, beim Auftreten der folgenden Ereignisse, eigene

Routinen zur Ausfuhrung zu bringen: Taskerzeugung, Taskinitialisierung, Taskloschung, Kon-

textwechsel, Taskstart, Taskbeendigung und beim Auftreten von Fehlern. RTEMS wird uber

die entsprechenden Eintrittspunkte, die die User Extension ausmachen, durch folgende Da-

tenstruktur in Kenntnis gesetzt.

typedef struct {

rtems_task_create_extension thread_create;

rtems_task_start_extension thread_start;

rtems_task_restart_extension thread_restart;

rtems_task_delete_extension thread_delete;

rtems_task_switch_extension thread_switch;

rtems_task_begin_extension thread_begin;

rtems_task_exitted_extension thread_exitted;

rtems_fatal_extension fatal;

} rtems_extensions_table;

18 2 Grundlagen

2.2.0.5 Konfiguration

Die Konfigurationsinformationen, wie beispielsweise die Lange der Ticks, die Angabe des

Initialisierungstasks und die Anzahl der User Extensions, werden in einer speziellen Daten-

struktur, der Configuration Table, abgelegt. Diese muss bei der Initialisierung von RTEMS

vorliegen. Die Configuration Table hat folgenden Aufbau.

typedef struct {

void *work_space_start;

rtems_unsigned32 work_space_size;

rtems_unsigned32 maximum_extensions;

rtems_unsigned32 microseconds_per_tick;

rtems_unsigned32 ticks_per_timeslice;

rtems_unsigned32 maximum_devices;

rtems_unsigned32 maximum_drivers;

rtems_unsigned32 number_of_device_drivers;

rtems_driver_address_table *Device_driver_table;

rtems_unsigned32 number_of_initial_extensions;

rtems_extensions_table *User_extension_table;

rtems_multiprocessing_table *User_multiprocessing_table;

rtems_api_configuration_table *RTEMS_api_configuration;

posix_api_configuration_table *POSIX_api_configuration;

} rtems_configuration_table;

Neben der aufwendigen Moglichkeit jede Configuration Table einzeln zu editieren, bietet RTEMS

die Option, die Konfiguration uber Makros vorzunehmen. Zu diesem Zweck halt RTEMS die

C-Header-Datei confdefs.h bereit. In folgendem Beispiel wird ein simples System mit einer

”Message Queue“ und einer Zeitscheibenlange von 50ms konfiguriert.

#define CONFIGURE_APPLICATION_NEEDS_CONSOLE_DRIVER

#define CONFIGURE_APPLICATION_NEEDS_CLOCK_DRIVER

#define CONFIGURE_MICROSECONDS_PER_TICK 1000 /* 1 millisecond */

#define CONFIGURE_TICKS_PER_TIMESLICE 50 /* 50 milliseconds */

#define CONFIGURE_MAXIMUM_TASKS 4

#define CONFIGURE_RTEMS_INIT_TASKS_TABLE

Das System startet mit dem Initialisierungtask Init. Es weist einen Konsolentreiber, fur Stan-

dard Ein- und Ausgaben und einen Clocktreiber, der fur die Verwaltung der Ticks verantwort-

lich ist, auf. Neben der Bestimmung der Zeitscheibenlange, werden hier maximal vier Tasks

2.3 Scheduling-Algorithmen 19

zugelassen. Die CONFIGURE INIT-Konstante lost das Konfigurieren der eigentlichen Daten-

struktur aus. Die Default-Konfigurationen, der nicht angesprochenen Komponenten, werden

auf ihr absolutes Minimum gesetzt.

Auf Basis der Datei confdefs.hwird der Speicherbedarf des RTEMS-Workspace geschatzt.

Die Qualitat der Schatzung hangt dabei von den gemachten Angaben ab. Zu einer Uber-

schatzung des Speicherbedarfes kann eine unnotige Resevierung des Floatingpoint-Kontextes

fuhren. Grunde fur eine Unterschatzung sind: benotigter Stack der Tasks uberschreitet die

Defaultgroße, Nachrichten-, Geratetreiber-, Netzwerkstack-, oder ”Add-On Library“- Bedurf-

nisse werden nicht berucksichtigt. Es ist also wichtig, ausreichend Informationen in der Konfi-

gurationsdatei bereit zu stellen.

2.3 Scheduling-Algorithmen

Wenn ein einzelner Prozessor eine Menge P von Tasks ausfuhren soll, ist es notwendig,

nach einer bestimmten Regel, diese Tasks der CPU zuzuweisen. Diese Regeln werden als

Abbildung 2.10: Parameter eines Tasks in einer Echtzeitumgebung

Scheduling-Politik bezeichnet [But02]. Das Regelwerk, das zu jedem Zeitpunkt eindeutig die

Ausfuhrungsreihenfolge der Tasks definiert, wird als Scheduling-Algorithmus bezeichnet. Die

eigentliche Durchfuhrung des Zuweisens eines Tasks an die CPU wird dispatchen genannt.

Im folgenden werden nur voneinander unabhangige Tasks betrachtet. Formal lasst sich ein

Schedule wie folgt definieren.

Def.: Ein Schedule ist eine Funktion σ : R+ → N fur die gilt ∀t ∈ R+, ∃t1, t2 mit t ∈ [t1, t2)und ∀t , ∈ [t1, t2): σ(t) = σ(t ,). σ(t) nimmt also positive ganzzahlige Werte k an. σ(t) = k, mit

k > 0 bedeutet, dass Task k zum Zeitpunkt t ausgefuhrt wird. σ(t) = 0 bedeutet, dass sich die

CPU im Leerlauf befindet.

Ein Schedule wird als ”durchfuhrbar“ bezeichnet, wenn alle Tasks, mit Berucksichtigung ei-

ner Menge von einschrankenden Parametern, terminieren. Die wichtigsten Parameter eines

Tasks i ∈ P in einem Echtzeitumfeld sind:

20 2 Grundlagen

• Ankunftszeit ai: Zeitpunkt an dem i ∈ P ausfuhrbereit ist.

• Ausfuhrungszeit Ci: Zeitperiode die benotigt wird um i ∈ P zu verarbeiten.

• Deadline di: Zeitpunkt bis wann i ∈ P terminiert sein muss.

• Startzeitpunkt si: Zeitpunkt an dem i ∈ P mit der Ausfuhrung beginnt.

• Terminierungszeitpunkt fi: Zeitpunkt an dem die Verarbeitung von i ∈ P abgeschlos-

sen ist.

• Verzug Li: Li = fi− di. Zeitverzug von i ∈ P. Ist negativ, wenn Deadline eingehalten

wird.

• Maximalverzug LMAX : LMAX = max∀i∈P (Li).

• Puffer Xi: Xi = di−ai−Ci. Maximaler Verzug des Startzeitpunktes, bei dem Deadline

eingehalten wird.

Abbildung 2.10 visualisiert die Zusammenhange der Parameter. Scheduling-Algorithmen las-

sen sich nach verschiedenen Kriterien klassifizieren. Abbildung 2.11 zeigt eine mogliche Ein-

teilung [Mar06]. Grundsatzlich unterscheidet man harte und weiche Deadlines voneinander.

Abbildung 2.11: Klassifizierung von Scheduling-Algorithmen

Weiche Deadlines findet man vor allem im Bereich der Standardbetriebssysteme. Sie spie-

len in der Umgebung der eingebetteten Systeme eine untergeordnete Rolle. Daher wird diese

Klasse nicht weiter betrachtet. Scheduling-Algorithmen mit harten Deadlines lassen sich nach

der Haufigkeit und Regelmaßigkeit des Auftretens der einzulastenden Tasks unterscheiden.

Dazu folgende Definitionen:

Def.: Tasks, die alle z Zeiteinheiten ausgefuhrt werden mussen, heißen periodische Tasks.

z wird als Periode bezeichnet. Jede Ausfuhrung eines periodischen Tasks heißt Job.

Def.: Alle Tasks, die nicht periodisch sind, sind unperiodisch.

2.4 Optimierungs-Algorithmen 21

Def.: Unperiodische Tasks, die zu unvorhersehbaren Zeitpunkten die CPU anfordern, sind

sporadische Tasks.

Nicht-preemptive Scheduling-Algorithmen basieren auf der Annahme, dass die auszufuhren-

den Tasks bis zum Schluss, d.h. ohne sie unterbrechen zu durfen, auf der CPU eingelas-

tet bleiben. Bei Tasks mit langer Ausfuhrungszeit, fuhrt dies zu sehr langen Antwortzeiten

auf externe Ereignisse. Preemptive Scheduler sind daher in der Regel die bessere, wenn

auch bezuglich der Implementierung, aufwendigere Wahl. Des weiteren lassen sich statische

und dynamische Algorithmen unterscheiden. Dynamisch bedeutet in diesem Zusammenhang,

dass die Scheduling-Politiken auf, zur Laufzeit verandernden, Parametern basieren. Bei sta-

tischen Algorithmen verandern sich diese nicht. In [But02] wird zusatzlich noch zwischen on-

line und off-line unterschieden. On-line Algorithmen treffen ihre Entscheidungen zur Laufzeit

und off-line Algorithmen vor dem Start des Multiprozesssystems.

Das RoundRobin-Schedule wurde bereits in Kapitel 1.2 vorgestellt. Einsortieren lasst es sich

in die Klasse der statischen, preemptiven, off-line Algorithmen. In dieser Arbeit wird davon

ausgegangen, dass alle Tasks zum Zeitpunkt t = 0 zur Ausfuhrung bereitstehen. In diesem

Fall ist das betrachtete Schedule nicht-periodisch. Es ist aber prinzipiell moglich, in die Warte-

schlange der RoundRobin-Datenstruktur, periodisch oder sporadisch auftretende Tasks ein-

zusortieren.

Wenn davon ausgegangen wird, dass alle Tasks zum gleichen Zeitpunkt ausfuhrbereit sind

und die Deadlines aller Tasks bekannt sind, liefert der Scheduling-Algorithmus ”Earliest Due

Date“ (EDD) einen minimalen Maximalverzug. Dazu sortiert EDD die Tasks nach ihren Dead-

lines und bringt sie in entsprechender Reihenfolge zur Ausfuhrung. Wenn der Maximalver-

zug negativ ist, halten alle Tasks ihre Deadline ein. Dieser statische, nicht-preemptive, nicht-

periodische, off-line Algorithmuss basiert auf Jackson´s Gesetzt [Jac55]: ”Given a set of n

independent tasks, any algorithm that executes the tasks in order of nondecreasing deadlines

is optimal with respect to minimizing the maximum lateness.“

2.4 Optimierungs-Algorithmen

Im Folgenden werden einige Ansatze zur Losung von Optimierungsaufgaben vorgestellt, die

immer dann zur Geltung kommen, wenn analytische Ansatze versagen oder keine Algorith-

men fur die Problemstellung bekannt sind. Analytische Ansatze konnen ungeeignet sein, weil

[Sch77]:

• die Voraussetzung der Stetigkeit der Zielfunktion und ihrer Ableitungen nicht gegeben

ist.

• die Bedingungsgleichungen sich nicht auflosen lassen.

22 2 Grundlagen

• die Losung der Bedingungsgleichungen nicht zum gewunschten Optimum (lokales Op-

timum, Sattelpunkt) fuhrt.

2.4.1 Integer Linear Programming

Unter Integer Linear Programming oder kurz ILP, wird das Optimieren linearer Funktionen

unter Berucksichtung von linearen Nebenbedingungen in Form von Gleichungen und Unglei-

chungen verstanden. Die Standardform der ILP-Gleichungen sieht wie folgt aus.

f (x) = w1x1 + ...wnxn (2.2)

ai1x1 + ...+ainxn ≥ bi, 1≤ i≤ m (2.3)

x j ∈ Z, 1≤ j ≤ n (2.4)

w j ∈ R, 1≤ j ≤ n (2.5)

ai j ∈ R, 1≤ i≤ m, 1≤ j ≤ n (2.6)

Gleichung 2.2 stellt die Zielfunktion dar. Diese wird entweder minimiert oder maximiert. Dabei

mussen die Nebenbedingungen in Form der Funktionen 2.3 bis 2.6 erfullt bleiben. Haufig

werden Probleme betrachtet in denen der Wertebereich der xi auf {0,1} eingeschrankt ist.

[Weg99] hat gezeigt, dass Probleme dieser Form NP-hart sind. Dennoch lassen sich fur die

meisten Probleme Losungen in akzeptabler Zeit bestimmen.

In dieser Arbeit wird zur Losung von ILP-Problemen, CPLEX der Firma ILOG, eingesetzt

[ILC08].

2.4.2 Bergsteigeralgorithmus

Der Bergsteigeralgorithmus, oder englisch ”Hill Climbing“, stellt eine einfache Methode zur

heuristischen Losung von Optimierungsproblemen dar. Der Ausdruck leitet sich aus der Vor-

gehensweise dieser Algorithmen ab, die sich, bei der Suche des Maximums, an der intuitiven

Art eines Bergsteigers orientiert, der sich vom Tal aus zum Gipfel eine Berges emportastet.

Bei der Suche nach dem Minimum kehrt sich die Richtung der Bewegung um.

Von einem beliebigen Startpunkt in einer ”Wertelandschaft“ wird solange eine, nach einer be-

stimmten Kostenfunktion bewertete, bessere Position gewahlt, bis keine Verbesserung mehr

moglich ist. Das Problem bei diesem Verfahren ist, dass es sehr leicht in lokalen Optima

”stecken bleibt“. Ein Losungsansatz ist, den Bergsteigeralgorithmus von verschiedenen Posi-

tionen aus zu wiederholen [Sch77]. Außerdem ist es nicht immer leicht, ein geeignetes Ab-

bruchkriterium festzulegen.

2.4 Optimierungs-Algorithmen 23

2.4.3 Simulated Annealing

Simulated Annealing stellt eine Heuristik zur Losung von kombinatorischen Optimierungspro-

blemen dar. Vorbild fur diese Methode ist das Abkuhlen von kristallinen Flussigkeiten.

Bei Anwendung dieser Heuristik werden bestimmte Systemkonfigurationen Anderungen un-

terworfen. Das Besondere dabei ist, dass, bezuglich einer Kostenfunktion, mit einer gewissen

Wahrscheinlichkeit auch Verschlechterungen in Kauf genommen werden. Dadurch soll ver-

mieden werden in lokalen Optima ”stecken zu bleiben“. Ein maßgebender Parameter beim

Simulated Annealing ist die Temperatur. Sie hat ebenfalls Einfluss auf die Wahrscheinlichkeit,

mit der schlechtere Konfigurationen akzeptiert werden und auf die Auspragung der Ande-

rungen, die an den Systemkonfigurationen vorgenommen werden. Ein typischer Simulated

Annealing- Algorithmus sieht wie folgt aus.

void simulatedannealing(int MaxT, <datentyp> * System)

{

int i = 0;

int T = MaxT;

Konfiguration = Anfangskonfiguration(System);

while ( !(Abbruchkriterium(i,T) )

{

while ( Schleifenende(T) )

{

NeueKonfiguration = Variation(Konfiguration, T);

delta=Beurteilung(NeueKonfiguration,Konfiguration);

if (delta < 0 )

{

Konfiguration = NeueKonfiguration;

}

else if ( KleinGenug(delta, T, Zufall(0,1)) )

{

Konfiguration = NeueKonfiguration;

}

}

T = NeuesT(i, T);

i++;

}

}

Zunachst wird die Temperatur auf einen hohen Wert MaxT gesetzt und eine Anfangskonfigura-

tion erzeugt. Dies erfolgt in der Regel nach dem Zufallsprinzip. Die Temperatur wird nach dem

Durchlauf der inneren While-Schleife durch die Funktion NeuesT(i,T) langsam reduziert.

24 2 Grundlagen

Fur jeden Wert der Temperatur werden in der inneren While-Schleife mit Hilfe der Funktion

Variation(Konfiguration, T), in Abhangigkeit der Temperatur, zufallig neue Konfi-

gurationen erzeugt. Wenn diese Anderung, bezuglich der Kostenfunktion, eine Verbesserung

darstellt, wird sie ubernommen. Andernfalls wird mit Hilfe von KleinGenug(delta, T,

Zufall(0,1)) entschieden, ob nicht auch eine Verschlechterung in Kauf genommen wird.

Die innere Schleife wird nach einer von T abhangigen Anzahl an Iterationen abgebrochen. Die

Funktion Abbruchkriterium(i,T) bestimmt, wieder abhangig von der Temperatur und

den durchgefuhrten Iterationen, wann der Algorithmus terminiert.

Die Resultate sind bei geeigneten Parametern in der Regel sehr gut. [LAK97] hat nachgewie-

sen, dass Simulated Annealing, bezuglich eines globalen Optimums, minimale Kosten liefern

kann, wenn gewisse Bedingungen eingehalten werden.

2.5 Pareto-Optimum

In Optimierungsproblemen, bei denen mehrere konkurrierende Ziele auftreten bzw. optimiert

werden sollen, ist keine eindeutige optimale Losung definiert. Statt dessen ergibt sich eine

Losungsmenge, in der die Verbesserung eines Zieles die Verschlechterung eines anderen

Zieles zur Folge hatte. Dies stellt eine Losungsmenge der optimalen Kompromisse dar. Sol-

che Mengen werden als Pareto-optimal bezeichnet. Die Losungen lassen sich in einem n-

dimensionalen Diagramm, der n Optimierungsziele als Punkte, darstellen.

2.6 Verwandte Arbeiten

Dieser Arbeit liegt ein Multiprozesssystem mit einer Cache- oder Scratchpad- basierten Spei-

cherhierarchie und Betriebssystemunterstutzung zugrunde. Dabei soll die Energie- und Lauf-

zeiteffizienz bei unterschiedlichen Zeitscheibenlangen analysiert und im Anschluss eine Zeit-

scheibenlangenoptimierung durchgefuhrt werden. Im Folgenden werden Arbeiten vorgestellt,

die ahnliche Ansatze verfolgen oder als Grundlage fur diese Arbeit dienen.

Falk, Plazar et al. [FPT07] haben sich mit der Laufzeiteffizienz und Vorhersagbarkeit von

Cache-basierten Systemen beschaftigt. Ein grundlegendes Problem von Caches ist, dass es

nahezu unmoglich ist, vorherzusagen ob ein Zugriff in einem Cache-Hit oder in einem Cache-

Miss resultieren wird. Dies fuhrt zu einer starken Uberschatzung der WCETs. In dieser Arbeit

werden Optimierungstechniken vorgestellt, die unter Berucksichtung des WCET-Pfades der

Programme und Ausnutzung von Cache-locking, die Vorhersagbarkeit der Laufzeiten dras-

tisch erhohen und die WCET bis zu 73% senken.

In [BSL+02] haben sich Banakar, Steinke et al. mit einer Alternative zu Caches, den Scratch-

pads beschaftigt. Hier werden zur Compilezeit, mit Hilfe eines Rucksack-Algorithmus, die

hochfrequentierten Daten und Instruktionen in den Scratchpad verschoben. Gegenstand der

Betrachtung sind Singleprozesssysteme. Es konnte gezeigt werden, dass der Einsatz von

2.6 Verwandte Arbeiten 25

SPMs, im Verhaltnis zu Caches, eine durchschnittliche Energieersparnis von 40% bringt. Die

Platzersparnis lag im Druchschnitt bei 33% und die Laufzeitverbesserung bei 18%.

Verschiedene Nutzungsstrategien fur den Scratchpad in Multiprozesssystemen zur Optimie-

rung der Energieeffizienz werden in [VPW+05] behandelt. Verma, Petzold et al. unterscheiden

dabei zwischen einer statischen Allokation, einer dynamischen Allokation und einem hybriden

Ansatz, der den Scratchpad in einen statischen und einen dynamischen Part aufgeteilt. Die-

se Strategien werden in dieser Arbeit fur das Betriebssystem RTEMS portiert und daher in

Kapitel 3 detailliert vorgestellt. Im Vergleich zu Allokationsstrategien, die den Scratchpad nur

fur einzelne Prozesse nutzbar machen, wird eine durchschnittliche Energieersparnis von 9%-

20% festgestellt. Außerdem werden Pareto-optimale Kurven der Benchmarks diskutiert, die

den Energiebedarf-Speichergroße-Tradeoff darstellen.

Die Basis fur die Portierung der Allokationsstrategien fur Multiprozesssysteme bildet der Ar-

beitsablauf aus [PFV+07]. Aufgrund der wachsenden Komplexitat von eingebetteten Syste-

men und dem damit einhergehenden vermehrten Einsatz von Betriebssystemen stellen Pyka,

Faßbach et al. einen Ansatz vor, den Scratchpad mit Hilfe einer Betriebssystemerweiterung,

dem Scratchpadmemory-Manager, zu nutzen. Dieser wird in Kapitel 5 zusammen mit den,

fur diese Arbeit ubernommenen Teilen des Arbeitsablauf, ausfuhrlich vorgestellt. Das Ziel in

[PFV+07] ist ebenfalls, den Energiebedarf zu senken. Dazu werden Online-Heuristiken ein-

gesetzt, die auf, zur Compilezeit gewonnenen Daten uber die Applikationen, zuruckgreifen.

Durch Einsatz dieser Heuristiken kann bis zu 83% an Energie eingespart werden.

26 2 Grundlagen

3 SPM-Allokations-Strategien fur mehrere Prozesse 27

Kapitel 3

SPM-Allokations-Strategien furmehrere Prozesse

In diesem Kapitel werden die SPM-Allokations-Strategien fur Multiprozesssysteme SAMP,

DAMP und HAMP vorgestellt. In [VPW+05] werden sie, aufgrund ihrer Funktionsweisen, als

”Non-Saving“, ”Saving“ und ”Hybrid“ bezeichnet. Die Aufgabe dieser Strategien ist es, in ei-

nem Multiprozesssystem mit Scratchpad eine Kostenfunktion der Prozesse zu optimieren.

Dazu stellt die SAMP-Strategie (”Non-Saving“) jedem Prozess einen fixen Anteil des SPM

zur Verfugung. Sie wird in Abschnitt 3.1 vorgestellt. Wohingegen, die in Abschnitt 3.2 vor-

gestellte, DAMP-Strategie (”Saving“) jedem Prozess den kompletten SPM verfugbar macht.

Dies setzt eine Aktualisierung des SPM bei jedem Kontextwechsel voraus. Die Allokations-

Strategie HAMP (”Hybrid“), Abschnitt 3.3, teilt den SPM in einen SAMP- und einen DAMP-Teil

auf.

In [VPW+05] wird der Energieverbrauch der Prozesse bei einem bestimmten Scratchpad-

Anteil als Kostenfunktion gewahlt. In dieser Arbeit wird der Energieverbrauch der, zu den Pro-

zessen gehorenden, Speicherobjekte als Kostenfunktion gewahlt. Speicherobjekte konnen

globale Variablen oder Funktionen sein. Es konnen also sowohl Daten- als auch Instruktions-

Objekte in den SPM ausgelagert werden.

Die Realisierung der SPM-Allokations-Strategien erfolgt mit Hilfe ganzzahliger Programmie-

rung. In [VPW+05] werden auch algorithmische Losungsansatze prasentiert. Fur die ILP-

Gleichungen stellt der Profit der Speicherobjekte die zentrale Konstante dar. Dieser ergibt

sich aus der Differenz des Energieverbrauchs fur Zugriffe auf das Speicherobjekt, wenn es

sich im Hauptspeicher befindet, und des Verbrauchs, wenn es im SPM liegt. Dabei wird des-

sen Speicherbedarf und die Haufigkeit, mit der auf das Objekt zugegriffen wird, berucksichtigt.

Def.: Profit(Speicherobj.) =

Anzahl(Lesezugr.) * [Energie(Lesezugr.,Hauptsp.) - Energie(Lesezugr.,SPM)] +

Anzahl(Schreibzugr.) * [Energie(Schreibzugr.,Hauptsp.) - Energie(Schreibzugr.,SPM)]

28 3 SPM-Allokations-Strategien fur mehrere Prozesse

Es wird zwischen lesenden und schreibenden Zugriffen unterschieden, da die Kosten fur

einen lesenden Zugriff auf den Hauptspeicher großer sind, als fur einen Schreibzugriff. Die

Kosten fur lesende und schreibende Zugriffe auf den SPM sind in etwa gleich groß.

3.1 Statische Allokation fur mehrere Prozesse (SAMP)

Die statische Allokationsmethode SAMP, teilt den Scratchpad-Speicher fest auf die beteiligten

Prozesse auf. Wie in Abbildung 3.1 verdeutlicht wird, wird jedem Prozess, zu jedem Zeit-

punkt, genau ein Anteil zugeteilt. Betrachtet werden im Folgenden nicht die Prozesse, son-

Abbildung 3.1: Statische Allokation fur mehrere Prozesse (SAMP)

dern direkt die Speicherobjekte in den Prozessen. Abhangig vom Profit werden sie entweder

in den SPM oder in den Hauptspeicher verschoben. Dabei wird die maximale Speicherka-

pazitat berucksichtigt. Die Problemstellung entspricht also genau der des NP-vollstandigen

Rucksackproblems. Die ILP-Gleichungen sehen wie folgt aus:

Variablen und Konstanten:

xi,p Binare Entscheidungsvariable, ist gleich 1, wenn sich das Speicherobjekt i,

das zu Prozess p gehort, im Scratchpad befindet und 0 sonst

Pi,p Profit des Speicherobjekts moi,p

Si,p Speicherbedarf des Speicherobjekts moi,p

SSPM Speicherkapazitat des Scratchpads

P Menge der Prozesse

Ip Menge der Speicherobjekte die zu Prozess p gehoren

Zielfunktion:

∑p∈P

∑i∈Ip

xi,p ∗Pi,p→ maximiere (3.1)

3.2 Dynamische Allokation fur mehrere Prozesse (DAMP) 29

Nebenbedingung:

∑p∈P

∑i∈Ip

xi,p ∗Si,p ≤ SSPM (3.2)

Die Zielfunktion 3.1 maximiert den Gesamtprofit. Die Nebenbedingung 3.2 sorgt fur die Ein-

haltung der Speicherkapazitat des SPM.

3.2 Dynamische Allokation fur mehrere Prozesse (DAMP)

Im Gegensatz zu SAMP, wird bei der dynamischen Allokation, wie in Abbildung 3.2 darge-

stellt, den einzelnen Prozessen, zu ihrer Ausfuhrungszeit, der komplette SPM zur Verfugung

gestellt. Dies bietet den Vorteil, dass insgesamt mehr Speicherobjekte in den SPM ausgela-

Abbildung 3.2: Dynamische Allokation fur mehrere Prozesse (DAMP)

gert werden konnen und somit potenziell mehr Profit erzielt werden kann. Dieser Profit ver-

mindert sich jedoch, da die Daten-Objekte des Prozesses, der unterbrochen wird, zuruck in

den Hauptspeicher kopiert und die Daten- und Instruktions-Objekte, des zur Ausfuhrung ge-

brachten Prozesses, in den SPM hineinkopiert werden mussen.

Die ILP-Gleichungen fur DAMP sehen wie folgt aus:


xi,p Binare Entscheidungsvariable, ist gleich 1, wenn sich das Speicherobjekt i,

das zu Prozess p gehort, im SPM befindet und 0 sonst

Pi,p Profit des Speicherobjekts mi,p

CMM→SPM,Si,p Kopierkosten fur das Speicherobjekt mi,p der Große Si,p,

Kopierrichtung: Vom Hauptspeicher in den Scratchpad

CSPM→MM,Si,p Kopierkosten fur das Speicherobjekt mi,p der Große Si,p,

Kopierrichtung: Vom Scratchpad in den Hauptspeicher


Di,p ist 1, wenn das Speicherobjekt mi,p ein Datenobjekt ist und 0 sonst

Bp gibt die Anzahl der Aufrufe des Prozess p an

Si,p Speicherbedarf des Speicherobjekts mi,p

SSPM Speicherkapazitat des Scratchpads



Zielfunktion:

∑p∈P

∑i∈Ip

xi,p ∗ (Pi,p− (CMM→SPM,Si,p +CSPM→MM,Si,p ∗Di,p)∗Bp)→ maximiere (3.3)

Nebenbedingung:

∀p ∈ P: ∑i∈Ip

xi,p ∗Si,p ≤ SSPM (3.4)

Die Zielfunktion 3.3 maximiert, wie auch die Funktion 3.1, den Gesamtprofit. Der Profit wird

bei der dynamischen Allokationsstrategie durch die Kopierkosten vermindert. Diese sind zum

Einen abhangig von der Objektgroße und zum Anderen von der Kopierrichtung. Die Kosten

fur Kopiervorgange vom Hauptspeicher in den Scratchpad sind hoher, als die Kopierkosten

fur die Gegenrichtung (CMM→SPM,Si,p > CSPM→MM,Si,p). Die Konstante Di,p sorgt dafur, dass

nur Datenobjekte in den Hauptspeicher zuruck kopiert werden. Instruktionsobjekte sind kei-

nen Anderungen unterworfen und verbleiben als Kopie im Hauptspeicher und mussen somit

nicht zuruckgeschrieben werden. Da kein Dirtybit fur Datenobjekte verwaltet wird, muss da-

von ausgegangen werden, dass ein schreibender Zugriff erfolgt ist. Dies wiederum macht ein

Zuruckschreiben notwendig. Bp gibt die Anzahl der Aufrufe des Prozess p an und somit die

notwendige Anzahl an Kopiervorgangen. Wenn die Laufzeit Cp des Prozesses p bekannt ist,

kann Bp wie folgt berechnet werden:

Bp = d(Cp/Q)−1e+1 (3.5)

Neben der Laufzeit des Prozess p spielt hier also auch die Zeitscheibenlange Q eine wesent-

liche Rolle.

Die Nebenbedingung 3.4 beschrankt die Auswahl der Speicherobjekte durch die Speicher-

kapazitat des SPM. Im Gegensatz zur Nebenbedingung 3.2 wird hier jeder Prozess separat

betrachtet.

3.3 Hybride Allokation fur mehrere Prozesse (HAMP)

In der hybriden Allokation fur mehrere Prozesse werden die beiden obigen Ansatze kombi-

niert. Der SPM wird also in einen statischen und einen dynamischen Teil, wie in Abbildung

3.3 dargestellt wird, aufgeteilt. Dabei hat jeder Prozess, zu jedem Zeitpunkt, einen festen An-

3.3 Hybride Allokation fur mehrere Prozesse (HAMP) 31

Abbildung 3.3: Hybride Allokation fur mehrere Prozesse (HAMP)

teil und zu seiner Ausfuhrungszeit den kompletten dynamischen Anteil zur Verfugung. Wie bei

DAMP muss der dynamische Teil des SPM bei jedem Kontextwechsel aktualisiert werden. Die

ILP-Gleichungen sehen wie folgt aus:


xp,d,s Binare Entscheidungsvariable, ist gleich 1, wenn der Prozess p einen

dynamischen Anteil von d Einheiten und einen statischen Anteil von s Einheiten hat

Pp,d,s Profit des Prozesses p bei einem dynamischen Anteil von d Einheiten und

einem statischen Anteil von s Einheiten

SSPM Speicherkapazitat des SPMs

Zielfunktion:

∑p∈P

SSPM

∑d=0

SSPM−d

∑s=0

xp,d,s ∗Pp,d,s→ maximiere (3.6)

Nebenbedingungen:

∀p ∈ P:SSPM

∑d=0

SSPM−d

∑s=0

xp,d,s = 1 (3.7)

∀l ∈ P: ∑p∈P

SSPM

∑d=0

SSPM−d

∑s=0

xp,d,s ∗ s+SSPM

∑d=0

SSPM−d

∑s=0

xl,d,s ∗d ≤ SSPM (3.8)

Im Unterschied zu den Zielfunktionen 3.1 und 3.3 maximiert die Zielfunktion fur HAMP 3.6

nicht den Profit bezogen auf die Speicherobjekte, sondern den Profit der Prozesse bei einem

bestimmten statischen und dynamischen Anteil. Diese Konstante wird mit Hilfe der, weiter

unten beschriebenen, ILP-Gleichungen der hybriden Allokation fur einen Prozess (HAOP) be-

stimmt. Sie liefert den maximalen Profit bei der gewahlten Aufteilung des Scratchpads eines

bestimmten Prozesses. Nebenbedingung 3.7 sorgt dafur, dass jeder Prozess nur einen sta-

tischen und einen dynamischen Anteil erhalt. Fur die Einhaltung der Scratchpad-Große ist


Bedingung 3.8 verantwortlich. Der linke Teil der Summe addiert die statischen Teile aller Pro-

zesse auf, wahrend der rechte Teil, fur einen festen Prozess l, den dynamischen Teil hinzufugt.

Zusammen darf die maximale Speicherkapazitat nicht uberschritten werden.

Um die obigen ILP-Gleichungen aufstellen zu konnen, ist es, wie bereits erwahnt, erforderlich

fur alle Prozesse den maximalen Profit bei allen moglichen Aufteilungen des Scratchpads, in

einen statischen und dynamischen Teil, zu bestimmen. Dies wird mit Hilfe der folgenden ILP-

Gleichungen fur HAOP realisiert, wobei hier wieder die Speicherobjekte betrachtet werden:


xsi,p Binare Entscheidungsvariable, ist gleich 1, wenn sich das Speicherobjekt i,

das zu Prozess p gehort, im statischen Teil des SPM befindet

und 0 sonst

xdi,p Binare Entscheidungsvariable, ist gleich 1, wenn sich das Speicherobjekt i,

das zu Prozess p gehort, im dynamischen Teil des SPM befindet

und 0 sonst

Pi,p Profit des Speicherobjekts moi,p

CMM→SPM,Si,p Kopierkosten fur das Speicherobjekt moi,p der Große Si,p,

Kopierrichtung: Vom Hauptspeicher in den Scratchpad

CSPM→MM,Si,p Kopierkosten fur das Speicherobjekt moi,p der Große Si,p,

Kopierrichtung: Vom Scratchpad in den Hauptspeicher

Di,p Ist 1, wenn das Speicherobjekt moi,p ein Datenobjekt ist und 0 sonst

Bp Gibt die Anzahl der Aufrufe des Prozesses p an

Si,p Speicherbedarf des Speicherobjekts moi,p

SsSPM Speicherkapazitat des statischen Scratchpad-Anteils

SdSPM Speicherkapazitat des dynamischen Scratchpad-Anteils



Zielfunktion:

∀p ∈ P: ∑i∈Ip

xsi,p ∗Pi,p + xd

i,p ∗ (Pi,p− (CMM→SPM,Si,p +CSPM→MM,Si,p ∗Di,p)∗Bp)→ maximiere

(3.9)

Nebenbedingungen:

∀p ∈ P: ∑i∈Ip

xsi,p ∗Si,p ≤ Ss

SPM (3.10)

∀p ∈ P: ∑i∈Ip

xdi,p ∗Si,p ≤ Sd

SPM (3.11)

∀p ∈ P, i ∈ IP: xsi,p + xd

i,p ≤ 1 (3.12)

3.3 Hybride Allokation fur mehrere Prozesse (HAMP) 33

Der linke Teil der Zielfunktion 3.9 wahlt die Speicherobjekte fur die SAMP-Komponente aus

und der Rechte, unter Berucksichtigung der Kopierkosten, wie in Abschnitt 3.2 beschrieben,

die Speicherobjekte fur die DAMP-Komponenten. Dies wird fur alle Prozesse berechnet. Die

Nebenbedingungen 3.10 und 3.11 schranken dabei die Anzahl der Speicherobjekte, durch die

Speicherkapazitat des statischen und dynamischen Teils, ein. Damit ein Speicherobjekt nicht

gleichzeitig in beide Teile verschoben wird, muss Nebenbedingung 3.12 beachtet werden.


4 Theoretische Betrachtung des Multiprozesssystems 35

Kapitel 4

Theoretische Betrachtung desMultiprozesssystems

In Abschnitt 4.1 wird zunachst auf das Verhalten von Multiprozesssystemen bei verschie-

denen Zeitscheibenlangen bezuglich der Terminierungszeitpunkte der einzelnen Prozesse

eingegangen. In den Abschnitten 4.1.1 und 4.1.2 wird der erwartete Einfluss der Zeitschei-

benlange auf Energieverbrauch und Laufzeit des Gesamtsystems diskutiert. Dabei werden

Systeme mit Cache und Systeme mit SPM betrachtet. Abschnitt 4.2 behandelt die grund-

legende Vorgehensweise bei der Zeitscheibenlangenoptimierung. Das, der Implementierung

der Optimierung zugrunde liegende Laufzeitmodell des RoundRobin-Schedules wird in Ab-

schnitt 4.3 vorgestellt.

Fur die folgenden Abschnitte, werden einige Definitionen benotigt. Zunachst wird das Refe-

renzsystem definiert, welches dieser Arbeit zu Grunde liegt.

Def. (Referenzsystem): Multiprozesssystem mit Anwendung eines RoundRobin-Schedule

(mit vorzeitiger Unterbrechung der Zeitscheibe, bei nicht Ausnutzung) und einer fixen Anzahl

an Prozessen, die alle zum Zeitpunkt t = 0 zur Ausfuhrung bereitstehen. Die Speicherhier-

achie besteht entweder aus SPM (mit fester Große) und Hauptspeicher mit Anwendung der

SPM-Allokations-Strategien SAMP, DAMP oder HAMP oder alternativ aus Cache (mit fester

Große) und Hauptspeicher.

Wenn ein Prozess vor Ablauf seiner Zeitscheibe terminiert, wird diese also nicht mit ”NoOp“s

aufgefullt, sondern der nachste Prozess aus der Warteschlange zur Ausfuhrung gebracht,

falls ein solcher existiert. Ein weiterer wichtiger Aspekt des RoundRobin-Schedules ist die

Antwortzeit der Prozesse. Diese lasst sich wie folgt bestimmen:

Def. (Antwortzeit):

RMPS = Q∗ (|P|−1)+CCS ∗ |P| (4.1)

36 4 Theoretische Betrachtung des Multiprozesssystems

Dabei steht |P| fur die Anzahl der Prozesse, CCS fur die Dauer eines Kontextwechsels und

Q fur die Zeitscheibenlange. Die Antwortzeit gibt also die maximale Zeitspanne an, bis ein

Prozess des Multiprozesssystems auf ein externes Ereignis reagieren kann. Dabei wird davon

ausgegangen, dass kein Prozess durch Interrupts unterbrochen wird. Die Antwortzeit hangt

neben der fixen Anzahl der Prozesse maßgeblich von der Zeitscheibenlange ab. Je kurzer

diese ist, desto kurzer ist die Antwortzeit. Wie in Kapitel 1.2 bereits beschrieben, stellt das

Verhaltnis von Zeitscheibenlange zu Overhead, oder kurz Quota, die zweite wichtige Große in

einem RoundRobin-Schedule dar. Der Quota wird ebenfalls durch die Lange der Zeitscheibe

stark beeinflusst.

Def. (Quota):

QUMPS =100

Q+CCS∗CCS (4.2)

Welchen Einfluss Anwortzeit und Quota auf die Optimierung haben, wird in den folgenden

Abschnitten deutlich.

4.1 Einfluss der Zeitscheibenlange auf das Multiprozesssystem

Grundsatzlich kann die Zeitscheibenlange (Q) in einem Multiprozesssystem mit einem Round-

Robin-Schedule, neben der Antwortzeit und Quota, auch Einfluss auf die Terminierungsrei-

henfolge der Prozesse haben und somit ebenfalls auf die Einhaltung der Deadlines.

Dieser Sachverhalt soll anhand eines Beispiels verdeutlicht werden. Dabei wird zur Verein-

fachung angenommen, dass die Ausfuhrungszeiten Cp der Prozesse bei allen Zeitscheiben-

langen unverandert bleiben. Angenommen, das zu betrachtende Multiprozesssystem besteht

aus vier Prozessen mit den folgenden Spezifikationen:

• Prozess 1: C1 = 10 Zeiteinheiten, d1 = 35 Zeiteinheiten




• Overhead fur Kontextwechsel: CCS = 1 Zeiteinheit

• Soll-Antwortzeit: 31 Zeiteinheit

• Soll-Quota: 15%

4.1 Einfluss der Zeitscheibenlange auf das Multiprozesssystem 37

Durch die Soll-Antwortzeit muss eine bestimmte Mindestzeitscheibenlange eingehalten wer-

den. Setzt man die Soll-Antwortzeit in die Formel 4.1 ein und lost sie nach Q auf, erhalt man

eine obere Grenze fur die Zeitscheibenlange. In diesem Beispiel ist dies Q = 9 Zeiteinhei-

ten. Bei einer Zeitscheibenlange von 9 Zeiteinheiten genugt fur die Prozesse 2 und 4 ein

Aufruf. Der Prozess 1 und der Prozess 3 benotigen einen zweiten Aufruf bis sie terminie-

ren. Abbildung 4.1(a) stellt dieses Szenario graphisch dar. Der Soll-Quota bildet eine untere

Abbildung 4.1: Beispiel fur den Einfluss der Zeitscheibenlange auf die Terminierungsreihenfolge. (a)Zeitscheibenlange von Q = 9 Zeiteinheiten. (b) Zeitscheibenlange von Q = 8 Zeiteinheiten.

Grenze fur die Zeitscheibenlange. Formel 4.2 lasst sich nach Q auflosen. Mit der Vorgabe

von QUMPS = 15% und einer Laufzeit fur den Kontextwechsel von CCS = 1 Zeiteinheit resultiert

eine Zeitscheibenlange von Q = 6 Zeiteinheiten. Ist die Zeitscheibe kurzer als 6 Zeiteinheiten,

ergibt sich ein schlechteres Verhaltnis als 15%. Grundsatzlich muss bei der Spezifikation der

Parameter eines Multiprozesssystems mit einem RoundRobin-Schedule darauf geachtet wer-

den, dass ein zulassiges Zeitscheibenlangen-Intervall existiert.

Bei einer Zeitscheibenlange von 9 Zeiteinheiten ergeben sich folgende Terminierungszeit-

punkte fur die Prozesse: f1 = 36 Zeiteinheiten, f2 = 16 Zeiteinheiten, f3 = 44 Zeiteinheiten

und f4 = 34 Zeiteinheiten. D.h. Prozesse 3 und 4 halten ihre Deadlines ein, wohingegen Pro-

zess 1 und Prozess 2 ihre Deadlines verpassen. Abbildung 4.1(b) stellt nun das Szenario dar,

in dem die Zeitscheibenlange von 9 Zeiteinheiten auf 8 Zeiteinheiten verkurzt ist. Die Pro-

zesse 1 und 3 sind dadurch gezwungen, einen Teil ihrer Abarbeitung in den zweiten Aufruf

zu verlagern. Fur Prozesse 2 und 4 ergeben sich diesbezuglich keine Anderungen, da ih-

re Laufzeiten kurzer sind, als die Zeitscheibenlange. Durch die Verlagerung von Prozess 3

profitieren die Terminierungszeitpunkte der Prozesse 1 und 4, da Prozess 3 fur den ersten

Aufruf nur noch 8 Zeiteinheiten, statt wie zuvor 9 Zeiteinheiten, zur Verfugung stehen. Da-

durch verschieben sich die Terminierungszeitpunkte der Prozesse 1 und 4 nach vorn. Der

Terminierungszeitpunkt von Prozess 1 betragt bei der Zeitscheibenlange von 8 Zeiteinheiten

f1 = 35 Zeiteinheiten, statt wie zuvor f1 = 36 Zeiteinheiten. Der Terminierungzeitpunkt von

Prozess 4 hat sich sogar um 2 Zeiteinheiten, von f4 = 34 Zeiteinheiten auf f4 = 32 Zeitein-

heiten verschoben. Prozess 4 profitiert zusatzlich von der Umschichtung der Abarbeitung von

Prozess 1. Der Terminierungszeitpunkt von Prozess 2 wird ebenfalls positiv durch die Um-

schichtung von Prozess 1 beeinflusst. Durch die Verkurzung der Zeitscheibenlange von Q = 9


Zeiteinheiten auf Q = 8 Zeiteinheiten konnen alle Prozesse ihre Deadlines einhalten.

Der Scheduling Algorithmus ”Earliest Due Date“ (EDD) (Kapitel 2.3) liefert fur Systeme, in

denen alle Prozesse zum Zeitpunkt t = 0 zur Ausfuhrung bereitstehen, ein Schedule, bei dem

alle Prozesse ihre Deadlines einhalten, falls ein solches existiert. Wenn jedoch eine bestimmte

Antwortzeit eingehalten werden soll, liefert auch EDD kein optimales Schedule. Dies zeigt die

Anwendung von EDD auf das obige Beispiel. Es ergibt sich folgende Ausfuhrungsreihenfolge:

1. Prozess 2 (d2 = 15)

2. Prozess 1 (d1 = 35)

3. Prozess 4 (d4 = 37)

4. Prozess 3 (d3 = 44)

Wenn die Prozesse nicht unterbrochen werden, ergibt sich ein Maximalverzug von −2. Das

bedeutet, dass alle Prozesse ihre Deadlines einhalten. EDD liefert also einen optimalen Sche-

dule. Durch die Soll-Antwortzeit muss jedoch eine Mindestzeitscheibenlange von 9 Zeiteinhei-

ten eingehalten werden. Abbildung 4.2 stellt das obige Beispiel mit veranderter Ausfuhrungs-

reihenfolge graphisch dar. Trotz der Ausfuhrungsreihenfolge, die durch das EDD-Schedule

Abbildung 4.2: Ausfuhrungsreihenfolge nach EDD-Schedule mit einer Zeitscheibenlange von Q = 9Zeiteinheiten

vorgegeben wird, konnen nicht alle Deadlines eingehalten werden. Erst durch die Verkurzung

der Zeitscheibe auf Q = 8 Zeiteinheiten, liegen die Terminierungszeitpunkte der Prozesse vor

den Deadlines.

Der Terminierungszeitpunkt des Gesamtsystems verschiebt sich spatestens dann nach hin-

ten, wenn durch die verkurzte Zeitscheibenlange ein oder mehrere Prozesse weitere Aufrufe

benotigen. Dabei verschiebt sich der Zeitpunkt um die Dauer der zusatzlichen Kontextwech-

sel. Der Terminierungszeitpunkt fur das Gesamtsystem, kann entweder uber das Maximum

aller fp, fur alle Prozesse p, bestimmt werden (Formel 4.6) oder ohne Umwege mit folgender

Formel:

fMPS = (∑p∈P

Cp +(Bp−1)∗CCS)+(|P|)∗CCS (4.3)

Es werden also die Ausfuhrungszeiten Cp der Prozesse aufsummiert und die Unterbrechun-

gen in Form der Kontextwechsel (Bp−1)∗CCS berucksichtigt. Bp gibt die Anzahl der Aufrufe

von Prozess p an. In Abschnitt 4.3 wird Bp formal definiert (Formel 4.9). Bp− 1 entspricht

der Anzahl der Unterbrechungen. Da auch ein gewisser Overhead auftritt, wenn die Prozesse


nacheinander eingelastet werden, werden, abhangig von der Anzahl der Prozesse |P|, weite-

re Kosten hinzu addiert. Vereinfachend wird angenommen, dass diese gleich den Kosten fur

einen Kontexwechsel bei Preemption sind. Angewendet auf das Beispiel, welches in Abbil-

dung 4.1(a) dargestellt ist, ergibt sich nach der Formel 4.3:

fMPS = 10+1∗1 +

5+0∗1 +

16+1∗1 +

7+0∗1 +

4 = 44

Die Zeitscheibenlange hat also nicht nur großen Einfluss auf die Terminierungszeitpunkte

der einzelnen Prozesse, sondern auch auf die Laufzeit des Gesamtsystems. Dadurch wird

ebenfalls der Energieverbrauch beeinflusst.

In den folgenden beiden Unterkapiteln wird der erwartete Einfluss der Zeitscheibenlange auf

den Energieverbrauch und auf die Laufzeit des Gesamtsystems behandelt. Dabei wird zuna-

chst ein Multiprozesssystem betrachtet, dessen Speicherhierarchie aus Hauptspeicher und

Cache besteht. Im Anschluss wird auf ein Multiprozesssystem mit einer Speicherhierarchie,

bestehend aus Hauptspeicher und SPM mit Anwendung der Allokations-Strategien SAMP,

DAMP oder HAMP, eingegangen.

4.1.1 Einfluss der Zeitscheibenlange auf Multiprozesssysteme mit Cache

In der Einleitung wird davon ausgegangen, dass sich die Laufzeiten der Prozesse, Cp, bei un-

terschiedlichen Zeitscheibenlangen nicht verandern. Dies kann auf das Referenzsystem mit

Cache nicht ubertragen werden. Fur das Referenzsystem mit Cache als Pufferspeicher, er-

folgt das Aktualisieren durch die Verwaltungshardware im Cache selbst. Somit verlagert sich

diese in die Ausfuhrungszeit der Prozesse. Dadurch ist der Overhead relativ klein, die nutz-

bare Zeitscheibenlange variiert aber durch das Auftreten von Cache-Misses und die damit

einhergehenden zusatzlichen Wartezyklen. Prinzipiell sollten lange Zeitscheiben fur ein Multi-

prozesssystem mit einer Speicherhierarchie bestehend aus Cache und Hauptspeicher vorteil-

hafter sein als kurze Zeitscheiben. Dennoch kann es in einem System mit wenigen Prozessen

und großen Caches dazu fuhren, dass eine Verkurzung der Zeitscheibe, kurzere Laufzeiten

und weniger Energieverbrauch, wie in den Abbildungen 4.3 und 4.4 dargestellt ist, zur Fol-

ge hat. Da die Aktualisierung des Caches durch das Verdrangen alter Speicherobjekte durch

neue Speicherobjekte erfolgt, kann es bei einer hinreichend kurzen Zeitscheibe passieren,

dass die Speicherobjekte des wieder zur Ausfuhrung kommenden Prozesses nicht verdrangt

wurden. Das Vorhandensein der benotigten Speicherobjekte im Pufferspeicher kann sich po-

sitiv auf den Energie- und Laufzeitbedarf des Systems auswirken. Im Falle einer langeren

Zeitscheibe hatte es eventuell zu einer Verdrangung kommen konnen.

Energie- und Laufzeitbedarf des Systems sollten relativ stark korrelieren, da das Aktualisieren


Abbildung 4.3: Erwartetes Verhalten bzgl.des Energiebedarfs von Cache-basiertenSystemen bei unterschiedlichen Zeitschei-benlangen

Abbildung 4.4: Erwartetes Verhalten bzgl.der Laufzeit von Cache-basierten Systemenbei unterschiedlichen Zeitscheibenlangen

des Caches sowohl den Laufzeit- als auch den Energiebedarf steigen lasst.

Großere Assoziativitaten haben einen reduzierenden Einfluss auf die Anzahl der Cache-

Misses [HP03]. Daher sollten auch Caches mit hoher Assoziativitat bei allen Zeitscheiben-

langen vorteilhaft bezuglich der Laufzeit- und Energieeffizienz sein.

4.1.2 Einfluss der Zeitscheibenlange auf Multiprozesssysteme mit SPM

Fur das Referenzsystem mit SPM und Anwendung der SPM-Allokations-Strategie DAMP

oder HAMP wird die Aktualisierung des Pufferspeichers wahrend der Kontextwechsel durch-

gefuhrt. Die Allokations-Strategie SAMP macht die Aktualisierung ganzlich uberflussig. Da-

durch steht den Prozessen die komplette Zeitscheibenlange zur Abarbeitung zur Verfugung.

Hinzu kommt, dass SPMs ohne aufwendige Verwaltungsstrukturen auskommen. Zusammen

mit einer guten Analyse zur Compilezeit, sollte dadurch der Energie- und Laufzeitbedarf des

Referenzsystems mit SPM geringer ausfallen, als der Bedarf des Referenzsystems mit Ca-

che. Abbildung 4.5 und 4.6 stellen den erwarteten Energieverbrauch und die erwartete Lauf-

zeit fur die verschiedenen Zeitscheibenlangen dar. Da DAMP bei jedem Kontextwechsel die

Abbildung 4.5: Erwartetes Verhalten bzgl.des Energiebedarfs von SPM-basiertenSystemen bei unterschiedlichen Zeitschei-benlangen

Abbildung 4.6: Erwartetes Verhalten bzgl.der Laufzeit von SPM-basierten Systemen beiunterschiedlichen Zeitscheibenlangen

Speicherobjekte des alten Prozesses in den Hauptspeicher zuruck kopieren und die Objek-

te des neu zur Ausfuhrung gebrachten Prozesses in den SPM kopieren muss, sollten kurze

Zeitscheiben einen großeren Einfluss auf den Energie- und Laufzeitbedarf haben, als auf

SAMP. Da HAMP die Vorteile der beiden anderen Allokations-Strategien kombiniert, sollte

HAMP nie einen schlechteren Energiebedarf aufweisen. Durch die Moglichkeit der Partitio-


nierung in einen dynamischen und einen statischen Anteil sollte HAMP in der Regel sogar

einen geringeren Bedarf aufweisen. Generell gilt aber fur alle, in dieser Arbeit betrachteten

SPM-Allokations-Strategien die folgende These.

These 4.1.1 In dem Referenzsystem mit SPM gilt: Je langer die Zeitscheibe ist, desto gerin-

ger sind der Energiebedarf und die Laufzeit des Gesamtsystems.

Diese These wird grundlegend fur die in Abschnitt 4.2 vorgestellte Optimierung sein. Im Fol-

genden wird sie bewiesen. Zunachst wird auf den Energiebedarf und danach auf den Lauf-

zeitbedarf eingegangen.

Der Energiebedarf des Multiprozessystems setzt sich, wie in Formel 4.4 dargestellt, aus den

Energieverbrauchen, verursacht durch die Prozesse, und den Energieverbrauchen verursacht

durch die Kontextwechsel, zusammen.

Esys = (∑p∈P

Ep)+(ECS ∗ x) (4.4)

Ep steht fur den Energieverbrauch, der durch den Prozess p verursacht wird, wenn dieser oh-

ne Unterbrechung auf der CPU eingelastet wird. ECS steht fur den Energieverbrauch der durch

einen Kontextwechsel entsteht und x steht fur die Anzahl der auftretenden Kontextwechsel in

dem Multiprozesssystem. Dabei seien die Energiekosten, die nach den Energiemodellen (Ka-

pitel 2.1.4) bestimmt werden, fur den ARM7-Prozessor, den Speichermodulen und den Bus in

Ep und ECS enthalten.

Bei einer bestimmten SPM-Belegung, die durch SAMP bestimmt wurde, hat die Zeitscheibe

keinen Einfluss auf den Energieverbrauch der Prozesse, ∑p∈P Ep. Auch ECS, der Energiever-

brauch fur einen Kontextwechsel bleibt fix. Die einzige variable Große ist x. Es gilt:

x = (∑p∈P

(Bp−1))+ |P| (4.5)

Da auch Verwaltungsaufwand auftritt, wenn die Prozesse nicht unterbrochen und nacheinan-

der auf der CPU eingelastet werden, kommt zur Anzahl der Unterbrechungen innerhalb der

Prozesse selbst, ∑p∈P(Bp−1), noch die Unterbrechung zwischen den Prozessen hinzu, |P|.Die Anzahl der Prozessaufrufe, Bp, wird mit wachsender Zeitscheibenlange kleiner (Formel

4.9). Das bedeutet, dass sich fur SAMP der Energiebedarf mit wachsender Zeitscheibenlange

verringert.

Fur DAMP gilt die obige Aussage bezuglich x ebenso. Ep hangt, im Gegensatz zu SAMP,

von der Zeitscheibenlange ab. Durch Losung der ILP-Gleichungen 3.3 und 3.4 fur DAMP

wird der Energieverbrauch des Multiprozesssystems minimiert. Die Zeitscheibenlange geht

in die Zielfunktion 3.3 uber Bp, der Anzahl der Prozessaufrufe, ein. Da Bp mit wachsender

Zeitscheibenlange kleiner wird, verringern sich die Kopierkosten und der Profit der Speicher-

objekte steigt. Dadurch steht eine großere Menge von, potenziell in den SPM verschiebbaren,

Speicherobjekten zur Verfugung. D.h., dass wachsende Zeitscheibenlangen, beim Einsatz

der Allokations-Strategie DAMP, nicht nur x kleiner werden lasst, sondern auch positiv auf den


Energiebedarf, der durch Prozesse hervorgerufen wird, ∑p∈P Ep, einwirkt. Im schlimmsten Fall

bleibt die SPM-Belegung und somit auch der Energiebedarf Ep, bei wachsender Zeitschei-

benlange, unverandert. Lediglich die Kosten fur Kontextwechsel konnen steigen, da hier das

Umkopieren der Speicherobjekte durchgefuhrt wird. Allerdings werden diese in der Zielfunk-

tion 3.3 berucksichtigt. Sobald die Kopierkosten den Profit ubersteigen, werden die entspre-

chenden Speicherobjekte im Hauptspeicher belassen. Die These 4.1.1 besitzt also, im Bezug

auf den Energieverbrauch, auch fur DAMP Gultigkeit.

Da HAMP auf SAMP und DAMP reduzierbar ist, verringert sich auch bei Anwendung dieser

Allokations-Strategie mit wachsender Zeitscheibenlange, der Energiebedarf.

Bleibt der Beweis fur das Laufzeitverhalten. Die Gleichung 4.3 bestimmt den Terminierungs-

zeitpunkt eines Multiprozesssystems.

Fur die Allokations-Strategie SAMP sind die Ausfuhrungszeiten der Prozesse Cp unabhangig

von der Zeitscheibenlange. Auch die Anzahl der Prozesse und die Laufzeit fur den Kontext-

wechsel, CCS, sind fix. Somit sinkt die Laufzeit des Gesamtsystem mit fallender Anzahl der

Prozessaufrufe, Bp.

Fur DAMP wachst die Anzahl der potenziell in den SPM verschiebbaren Speicherobjekte mit

wachsender Zeitscheibenlange. Durch die 10-fach kurze Zugriffszeit auf Speicherobjekte im

SPM, im Vergleich zu Objekten im Hauptspeicher, hat eine wachsende Zeitscheibenlange

positiven Einfluss auf den Laufzeitbedarf, der durch die Prozesse verursacht wird, ∑p∈PCp.

Zumindest wird dieser, bei unveranderter SPM-Belegung, nicht großer. Die Anzahl der Pro-

zessaufrufe, ∑p∈P Bp, verringert sich somit zusatzlich. Die Laufzeit fur den Kontextwechsel CCS

kann durch das Verschieben von Speicherobjekten bei der Allokations-Strategie DAMP großer

werden. Dies wird jedoch implizit bei der Losung der ILP-Gleichungen von DAMP, durch Be-

achtung der Kopierkosten, berucksichtigt. Die Hohe des Energieverbrauchs beim Umkopieren

hangt von der Große und der Menge der Objekte ab. Fur den Laufzeitbedarf gilt die gleiche

Abhangigkeit. Kann ein Speicherobjekt profitabel bezuglich des Energieverbrauchs in den

SPM verschoben werden, so ist dies auch profitabel bezuglich der Laufzeit.

Da die HAMP-Strategie auf SAMP und DAMP reduzierbar ist, gilt die These 4.1.1 bezuglich

des Laufzeitverhaltens auch fur diese SPM-Allokations-Strategie.

4.2 Optimierung

Nach These 4.1.1 ist das Ziel der Optimierung die Maximierung der Zeitscheibenlange. Der

Idealfall fur den Energieverbrauch und fur die Laufzeit ware es, wenn jeder Prozess ohne

Unterbrechung auf der CPU eingelastet werden konnte. Die Vorgabe einer Antwortzeit und

die Einhaltung der Deadlines verhindern dies. Durch das Umsortieren der Terminierungszeit-

punkte fp der Prozesse beim systematischen Verkurzen der Zeitscheibenlange, angefangen

bei der maximalen Ausfuhrungszeit der Prozesse, Q = max∀p∈P(Cp), konnen sich Intervalle

4.2 Optimierung 43

von Zeitscheibenlangen ergeben, in denen alle Deadlines eingehalten werden und Intervalle

von Zeitscheibenlangen, in denen das nicht der Fall ist. Dazu folgendes Beispiel:






• Overhead fur Kontextwechsel: CCS = 10 Zeiteinheiten

Zur Vereinfachung wird angenommen, dass Cp, fur alle Prozesse konstant, also von der Zeit-

scheibenlange unabhangig ist. Es liegt also entweder ein System zugrunde, dessen Speicher-

hierarchie nur aus Hauptspeicher oder aus SPM mit Hauptspeicher besteht, in dem SAMP zur

Anwendung kommt. Die maximale Zeitscheibenlange wird auf Q = max(Cp) = 1700 gesetzt

und stetig in Zehnerschritten, bis auf Q = 1, reduziert. In Abbildung 4.7 sind auf der X-Achse

Abbildung 4.7: Anzahl der verpassten Deadlines bei unterschiedlichen Zeitscheibenlangen

die Zeitscheibenlangen, von Q = 1 bis Q = 1700, und auf der Y-Achse die Anzahl der verpass-

ten Deadlines abgetragen.

Die Ergebnisse sind auf Basis eines Laufzeitmodells gewonnen worden. Dieses Modell wird

in Abschnitt 4.3 vorgestellt und ist Teil der Implementierung der Optimierung.

Im Bereich zwischen Q = 1 und Q = 600 pendelt die Anzahl sehr stark. In den Zeitscheibenin-

tervallen Q ∈ [600,700] und Q ∈ [1000,1430] halten alle Prozesse ihre Deadline ein. Je großer

die Zeitscheibe ist, desto geringer sind auch die Schwankungen in der Anzahl der verpassten

Deadlines. Die Kernaussage dieses Beispiels, lasst sich in folgendem Satz zusammenfassen:

Satz 4.2.1 In dem Referenzsystem mit SPM konnen mehrere Intervalle von Zeitscheibenlangen

entstehen, in denen die Deadlines dp der beteiligten Prozesse p, eingehalten werden.


Im folgenden Abschnitt, wird das Verhalten des Multiprozessystems beim systematischen

Verkurzen der Zeitscheibenlange detaillierter analysiert. Dazu vorab einige Definitionen:

Def.: Ein Prozess p heißt zergliedert, genau dann wenn gilt: BQp < BQ−s

p , mit s ∈ N+. Die-

ser Prozess wird mit pz bezeichnet.

Def.: Es existiert genau ein pl ∈ P: fpl = max∀p∈P( fp)

Def.: Bezuglich der Menge der Prozesse im RoundRobin-Schedule wird folgende strenge

Ordnung festgelegt: ∀i, j ∈ P : i < j wenn i in der Warteschlange vor j eingereiht ist.

Ein Prozess wird dann als zergliedert bezeichnet, wenn sich bei Verkurzung der Zeitschei-

benlange, die Anzahl seiner benotigten Aufrufe erhoht. Der Prozess pl ist der Prozess, der

als letztes terminiert und somit fur fMPS verantwortlich ist. Nach Formel 4.3 hangt die Ge-

samtlaufzeit fMPS, bei fixen Cp nur von Bp, der Anzahl der Aufrufe der Prozesse, ab. Die

Gesamtlaufzeit verschiebt sich somit hochstens um (BQ−sp −BQ

p ) ∗ |pz|, bei einer Verkurzung

der Zeitscheibenlange um s Einheiten, nach hinten. Der Terminierungszeitpunkt fpl des Pro-

zesses pl verlagert sich um die entsprechende Zeitspanne nach hinten. pl ist also ein po-

tenzieller Kandidat, der beim Auftreten von zergliederten Prozessen pz seine Deadline ver-

passt. Außerdem verschiebt sich der Terminierungszeitpunkt des zergliederten Prozesses

ebenfalls nach hinten, wodurch pz seine Deadline verpassen kann. Fur alle Prozesse p, die

nicht durch die Verkurzung der Zeitscheibenlange zergliedert sind und die vor dem letzten

Prozess terminieren (∀p ∈ P: p 6= pz und p 6= pl), werden die Prozess-Anteile auf ihre letzte,

die maximal zulassige Lange nicht ausnutzende Zeitscheibe umgeschichtet. Sie profitieren

aber durch das Umschichten der Prozess-Anteile von pl und pz und konnen so ihre Deadline,

unter Umstanden, wieder einhalten.

In dem obigen Beispiel ist der Prozess 4, nach Verkleinerung der Zeitscheibenlange von

Q = 1700 auf Q = 1690, der erste zergliederte Prozess. Ab einer Lange von Q = 1430 sind

ausreichend Anteile von Prozess 4 umgeschichtet, so dass alle Prozesse ihre Deadline ein-

halten konnen. Bei Q = 990 zergliedern in diesem Beispiel gleich zwei Prozesse, 2 und 5.

Da Prozess 5 gleichzeitig der letzte Prozess ist der terminiert, erhoht sich die Gesamtzahl

der verpassten Deadlines auf 2. Bei Q = 700 konnten wieder ausreichend Prozess-Anteile

umgeschichtet werden, so dass kein Prozess mehr seine Deadline verpasst. Da Prozess 3

eine Ausfuhrungszeit von C3 = 600 hat, zergliedert dieser, sobald die Zeitscheibenlange 600

Zeiteinheiten unterschreitet. So erhoht sich ab dieser Lange, die Anzahl der verpassten Dead-

lines wieder und kann die Nullmarke in diesem Beispiel auch nicht wieder erreichen.

In dem Beispiel werden die Laufzeiten der Prozesse Cp als von der Zeitscheibenlange un-

abhangig angenommen. Prinzipiell konnen die oben gemachten Beobachtungen aber auch

auf die SPM-Allokations-Strategien DAMP und HAMP ubertragen werden. Da die Ausfuh-

rungszeiten der Prozesse, ∑p∈PCp, bei sinkenden Zeitscheibenlangen nicht kurzer werden,

verschieben sich die Terminierungszeitpunkte fp starker. Grundsatzlich hat aber auch hierfur

der Satz 4.2.1 seine Gultigkeit.

4.3 Laufzeitmodell fur ein RoundRobin-Schedule 45

Der Satz 4.2.1 ist entscheidend fur die Realisierung der Optimierung. Denn durch das po-

tenzielle Auftreten von mehreren Intervallen, in denen die Einschrankungen, wie Einhaltung

der Deadlines, Soll-Antwortzeit und Soll-Quota, alle erfullt sind, fallt die binare Suche als

Optimierungs-Algorithmus weg. Auch eine Losung mit Hilfe der ganzzahligen Programmie-

rung kommt nicht in Frage, da die dafur notigen Bedingungen nicht erfullt sind. Um die Anzahl

der eingehaltenen Deadlines bestimmen zu konnen, mussen die Terminierungszeitpunkte fp

der Prozesse bestimmt werden. Diese hangen aber von der Zeitscheibenlange ab. Da sie

auch in der Zielfunktion maximiert werden wurde, kann keine konvexe Nebenbedingung dies-

bezuglich aufgestellt werden. Die Optimierung wird daher mit einem Bergsteiger- und alterna-

tiv mit einem Simmulated Annealing- Algorithmus, wie in Kapitel 5.2 beschrieben, realisiert.

Abbildung 4.8 fasst die Einschrankungen noch einmal graphisch zusammen. Die dunklen Bal-

Abbildung 4.8: Zusammenfassung der Einschrankungen fur die Optimierung der Zeitscheibenlange

ken markieren unzulassige Zeitscheibenlangen. Das geforderte Verhaltnis von Overhead zu

Zeitscheibe bildet eine untere Grenze fur die Zeitscheibenlange. Die geforderte Antwortzeit

bildet eine obere Grenze. In diesem Intervall muss die maximale Zeitscheibenlange bestimmt

werden, in der alle Deadlines eingehalten werden.

4.3 Laufzeitmodell fur ein RoundRobin-Schedule

Um die Einhaltung der Deadlines bei der Optimierung zu berucksichtigen, mussen die Ter-

minierungszeitpunkte der Prozesse bestimmt werden konnen. Zu diesem Zweck wurde das

folgende Laufzeitmodell entwickelt.

Der Terminierungszeitpunkt fMPS bestimmt sich aus dem Maximum der Terminierungszeit-

punkte der einzelnen Prozesse. Es gilt also:

fMPS = max∀p∈P

fp (4.6)


Der Terminierungszeitpunkt des Prozesses p in einem RoundRobin-Schedule lasst sich wie

folgt bestimmen:

fp = ∑r∈[R1−1,...,RBp−1]

∑i∈P

[∆(i,r)+δ (i,r)CCS]α(p,r) (4.7)

mit

Rx = x-te Abarbeitung der Warteschlange, auch als Runde bezeichnet (4.8)

Bp = d(Cp/Q)−1e+1, Anzahl der Aufrufe fur Prozess p (4.9)

∆(i,r) =

Q wenn Q≤Ci− (r ∗Q)

Ci− (r ∗Q) wenn 0 < Ci− (r ∗Q) < Q

0 sonst

(4.10)

δ (i,r) =

1 wenn ∆(i,r) > 0

0 sonst(4.11)

α(p,r) =

0 wenn (r +1)∗Q≥Cp und p < i

1 sonst(4.12)

Die außere Summe in Formel 4.7 addiert alle Runden r auf, in denen der betrachtete Prozess

p aufgerufen wird. Dabei wird mit r = 0 begonnen. Die innere Summe addiert die Rechenzei-

ten der, in der betrachteten Runde, aktiven Prozesse zuzuglich des, fur den Kontextwechsel

anfallenden, Overheads (CCS) auf. Dazu wird mit Hilfe der Funktion ∆(i,r) bestimmt, ob der

Prozess i die volle Zeitscheibe ausnutzt oder schon vorher terminiert. Der entsprechende

Wert wird zuruckgegeben. Wenn Prozess i schon in einer fruheren Runde terminiert ist, wird

0 zuruckgegeben und folglich entfallt auch ein Kontextwechsel. Aus diesem Grund ist δ (i,r)dann 0, wenn ∆(i,r) 0 ist. Um den genauen Terminierungszeitpunkt des betrachteten Pro-

zesses p bestimmen zu konnen, muss es eine Moglichkeit geben, innerhalb der betrachteten

Runde r das Aufaddieren der nachfolgenden Prozesse zu unterbinden. Dafur wird α(p,r)eingesetzt. Diese Funktion ist genau dann 0, wenn der betrachtete Prozess p in der aktuell

betrachteten Runde r terminiert ist. Die Rechenzeit der nachfolgenden Prozesse (i > p) wird

dann nicht mehr hinzugefugt.

Wenn man das Modell auf das Beispiel aus Abschnitt 4.1 fur den Terminierungszeitpunkt f2

von Prozess 2 mit einer Zeitscheibenlange von Q = 8 anwendet, erhalt man fur die Anzahl der

betrachteten Runden:

B2 = d(5/8)−1e+1 = 1

Es wird also fur r = 0 einmal die innere Summe aufgerufen. Das sieht wie folgt aus:

f2 = (8+1∗1)∗1 +

(5+1∗1)∗1 +

(8+1∗1)∗0 +

(7+1∗1)∗0 = 15

4.3 Laufzeitmodell fur ein RoundRobin-Schedule 47

Am interessantesten sind die beiden letzten Summanden. Sie stehen fur die Prozesse 3 und

4. Da diese noch nicht vollstandig abgearbeitet sind, gibt ∆(i,r) die entsprechenden Laufzeiten

fur diese Runde zuruck. Auch δ (i,r) ist hier gleich 1 um den Overhead des Kontextwechsels

zu berucksichtigen. Da hier jedoch der Teminierungszeitpunkt von Prozess 2 bestimmt wer-

den soll, durfen sie nicht aufaddiert werden. Aus diesem Grund ist α(p,r) = 0. Das Ergebnis

mit f2 = 15 deckt sich mit der Abbildung 4.1(b).


5 Arbeitsablauf und Implementierung 49

Kapitel 5

Arbeitsablauf und Implementierung

In diesem Kapitel wird im Abschnitt 5.1 der Arbeitsablauf vorgestellt, der notwendig ist um die

SPM-Allokations-Strategien zu realisieren. Dabei wird zunachst ein Uberblick gegeben um

anschließend in den Abschnitten 5.1.1 bis 5.1.7 auf die einzelnen Schritte detailliert einzuge-

hen.

Im Abschnitt 5.2 wird die Implementierung der Zeitscheibenlangenoptimierung vorgestellt.

5.1 Uberblick uber den Arbeitsablauf

Abbildung 5.1 zeigt einen kompletten Uberblick uber den Arbeitsablauf. Die einzelnen Prozes-

se, die das zu analysierende Multiprozessystem ausmachen, werden zu einer C-Datei zusam-

mengefasst. Dabei mussen die Funktionen und Variablen der Prozesse eine bestimmte Syn-

tax einhalten, damit sie spater ihrem Prozess zugeordnet werden konnen. Die main-Funktion

der Prozesse muss folgende Syntax einhalten:

void main_task0(rtems_task_argument ignored)

{

...

stop_task(RTEMS_SELF);

}

Die main-Funktion muss zum Einen als main-Funktion des Prozesses mit einer bestimmten

Id, in diesem Beispiel ist dies Id=0, zu erkennen sein und zum Anderen muss sie vom Init-

Task von RTEMS als solche erkannt werden. Die Funktion stop task(RTEMS SELF) mel-

det den Prozess vom Betriebsystem ab. Dazu im Abschnitt 5.1.6 mehr. Alle weiteren Funk-

tionen und Variablen erhalten den Zusatz ” task<id>“. Neben der C-Datei, geht die Zeit-

scheibenlange in den Arbeitsablauf mit ein. Weitere Großen, die in der Abbildung 5.1 aus

Ubersichtlichkeitsgrunden nicht aufgefuhrt sind, welche aber vom Nutzer variiert werden kon-

50 5 Arbeitsablauf und Implementierung

nen, sind: SPM-Große und SPM-Allokations-Strategie.

Um die ILP-Gleichungen fur die verschiedenen SPM-Allokations-Strategien aufstellen zu kon-

nen, werden die Profite der Speicherobjekte benotigt. Sie werden mit Hilfe des profitAnnotator

Abbildung 5.1: Darstellung des Arbeitsablaufs

bestimmt und der Quellcode entsprechend annotiert (Abschnitt 5.1.1). Auf Basis der anno-

tierten C-Datei wird von dem outputGenerator eine Profildatei erzeugt (Abschnitt 5.1.2). In

dieser Profildatei sind alle Informationen enthalten die, fur die ILP-Gleichungen von SAMP,

DAMP und HAMP, von Bedeutung sind. ILP-Generatoren erstellen automatisch die Gleichun-

gen, gemaß Kapitel 3, welche dann von CPLEX gelost werden (Abschnitt 5.1.3). Den aus-

gewahlten Speicherobjekten muss noch eine feste Adresse innerhalb des SPM zugeordnet

werden. Diese Zuordnung wird vom addressGenerator realisiert und ist abhangig von der

Allokations-Strategie (Abschnitt 5.1.4). Die RTEMS-Erweiterung, welche den SPM nutzbar

macht, wird als ScratchPad-Memory-Manager, kurz SPMM, bezeichnet und in Abschnitt 5.1.6

vorgestellt. Diesem SPMM muss eine Datenstruktur zur Verfugung gestellt werden, aus der

5.1 Uberblick uber den Arbeitsablauf 51

hervor geht, welche Speicherobjekte, zu welcher Zeit, in den SPM verlagert werden sollen.

Diese wird von cplex2header auf Basis der getroffenen Auswahl und der berechneten Adres-

sen erzeugt (Abschnitt 5.1.5). Ergebnis des Arbeitsablaufs ist ein energiesparendes Multi-

prozesssystem mit einer Speicherhierarchie bestehend aus SPM und Hauptspeicher. Da die

Laufzeit der Prozesse im Vergleich zum Zeitpunkt der Erstellung der Profildatei verkurzt ist,

hat sich die Basis fur DAMP und HAMP, wegen der potenziell geringeren Anzahl der Prozess-

Aufrufe, geandert. Wenn sie geringer geworden ist, ist eine weitere Iteration mit angepasster

Profildatei erforderlich. Dieser Arbeitsschritt wird mit Hilfe von XAMPopt umgesetzt (Abschnitt

5.1.7).

Wie in Kapitel 2.6 bereits erwahnt, basiert der Arbeitsablauf auf [PFV+07]. Der profitAnno-

tator, outputGenerator, und Teile des SPMM, dazu gehoren die Verwaltungsstruktur und die

API, wurden daraus ubernommen. Um die Allokations-Strategien nutzbar zu machen, wurde

der SPMM um eine Datenstruktur (Abschnitt 5.1.5) und entsprechende Funktionen erwei-

tert. Im Folgenden werden nur die, fur die vorliegende Arbeit genutzten Funktionalitaten der

ubernommenen Programme beschrieben.

5.1.1 profitAnnotator

Der profitAnnotator ist grundlegend fur das Erstellen der ILP-Gleichungen fur SAMP, DAMP

und HAMP und fur die Benutzung des SPMM. Als Eingabe dient, wie oben beschrieben, die

angepasste C-Datei. Zunachst wird sie compiliert. Dabei wird eine memory-map-Datei er-

zeugt, in der die Positionierung und die Große aller Funktionen und globalen Variablen hinter-

legt ist. In der anschließenden Simulation mit Hilfe des MPARM wird eine Trace-Datei erzeugt,

in der alle Schreib- und Lesezugriffe abgelegt sind. Zusammen mit der memory-map-Datei

lassen sich die Schreib- und Lesezugriffe den entsprechenden Speicherobjekten zuordnen,

um die Profite, wie in Kapitel 3 definiert, zu bestimmen.

Die Speicherobjekte werden im Anschluss in Datenstrukturen eingetragen, die von der Erwei-

terung des Programmladers durch den SPMM, verarbeitet werden.

Abschließend werden alle Funktionen in separate Quelldateien verschoben, um den Compiler

dazu zu bringen, ausfuhrbaren Code zu erzeugen, der auf Instruktionsobjekte an beliebigen

Adressen zugreifen kann. Wurden sich die Objekte in einer Quelldatei befinden, wurden die

Aufrufe aus Optimierungsgrunden positionsabhangig erfolgen. Wurde eine Funktion in den

SPM verschoben, so ware eine relative Adressierung nicht moglich.

Die Quellcode-Transformationen werden mit Hilfe des ICD-C durchgefuhrt [ICD08].

5.1.2 outputGenerator

Der outputGenerator compiliert die vom profitAnnotator annotierte C-Datei mit speziellen Pa-

rametern. Beim anschließenden Simulationslauf wird so vom SPMM die Profildatei erstellt. In

dieser finden sich folgende Informationen:


• Anzahl der Prozess-Aufrufe

• Adressen der Speicherobjekte im Hauptspeicher

• Typ (Daten oder Instruktion) der Speicherobjekte

• Große der Speicherobjekte

• Profit der Speicherobjekte

Diese Informationen dienen den ILP-Generatoren der SPM-Allokations-Strategien als Einga-

be.

5.1.3 ILP-Generatoren

Die ILP-Generatoren erstellen fur SAMP, DAMP oder HAMP die ILP-Gleichungen, gemaß Ka-

pitel 3. Dazu parsen sie die Profildatei und fugen die Informationen in interne Datenstrukturen

ein, um eine Textdatei zu erzeugen, die CPLEX im Anschluss einlesen und das enthaltende

ILP-Problem losen kann.

Fur die Allokations-Strategien SAMP und DAMP ist das in einem Schritt realisierbar. Um die

ILP-Gleichungen fur die Strategie HAMP aufstellen zu konnen, mussen zunachst fur alle Kom-

binationen aus statischem und dynamischem Anteil des SPM die Gleichungen fur HAOP

aufgestellt und gelost werden. Dabei werden zu jedem optimalen Profit fur eine bestimmte

Aufteilung, die dazugehorenden Speicherobjekte in einer separaten Datei abgelegt.

5.1.4 addressGenerator

Da fur die betrachteten SPM-Allokations-Strategien nur statische Variablen und Funktionen

betrachtet werden, ergibt sich das Problem der Fragmentierung des Speichers, wie bei der

dynamischen Speicherallokation, nicht. Die Bestimmung der Adressen ist abhangig von der

gewahlten Allokations-Strategie, da es im Falle von DAMP und den dynamischen Teil von

HAMP zu einem Overlay kommt.

Fur die SAMP-Strategie dient die Ausgabedatei von CPLEX als Eingabe. Hier ist die optima-

le Auswahl der Speicherobjekte, samt Zuordnung der Prozesse, enthalten. Außerdem wird

aus der Eingabedatei fur CPLEX, in der die ILP-Gleichungen enthalten sind, die Informati-

on uber die Objektgroßen gewonnen. Die Basis-Adresse des SPMs ist 0x22000000. Nun

werden der Reihe nach den Speicherobjekten ihre Adresse zugeordnet. Dabei erhalt das

erste Speicherobjekt moi,p die Adresse 0x22000000. Dem folgenden Objekt mok,p wird die

Adresse 0x22000000 + Si,p zugeordnet, usw.. Abbildung 5.2 veranschaulicht dieses Vorge-

hen graphisch. Die Speicherobjekte des Prozesses 1 erhalten die Adressen im Bereich von

0x22000000 bis 0x22000000 + (∑i∈I1 Si,1) - S j,1, wenn mo j,1 das letzte Speicherobjekt des

Prozesses 1 ist. Der nachfolgende Prozess, in diesem Beispiel Prozess 2, erhalt dann die


Abbildung 5.2: Adressen-Generierung fur SAMP

Adresse 0x22000000 + ∑i∈I1 Si,1. In Abbildung 5.2 ist dies durch 0x22000000 + SP1 ange-

deutet.

Die Eingabedateien fur die DAMP-Strategien sind die gleichen, wie bei der SPM-Allokations-

Strategie SAMP. Die Adressbestimmung fur die Speicherobjekte funktioniert, aufgrund der

Nutzung des ganzen SPM pro Prozess, etwas anders. Bei der Bestimmung der Adressen fur

Abbildung 5.3: Adressen-Generierung fur DAMP

SAMP, ist die Zuordnung der Speicherobjekte zu den Prozessen, im Grunde, unbedeutend.

Diese Zuordnung ist fur DAMP wichtig. Es werden den Speicherobjekten der Reihenfolge nach

ihre Adressen zugeordnet. Das erste Speicherobjekt moi,p erhalt die Adresse 0x22000000.

Dem folgenden Objekt mok,p wird die Adresse 0x22000000 + Si,p zugeordnet. Dies wird

solange fortgefuhrt, bis alle Speicherobjekte des betrachteten Prozesses eine Adresse zu-

gewiesen bekommen haben. Die Adressvergabe fur den folgenden Prozess startet wieder

mit der Basis-Adresse 0x22000000. Dieses Verfahren wird in der Abbildung 5.3 beispielhaft

dargestellt. Die Speicherobjekte aller Prozesse liegen hier im Bereich von 0x22000000 bis

0x22000000 + (SSPM−Sx,p), dabei hat mx,p die hochste Adresse.

Aufgrund der hoheren Komplexitat von HAMP, ist das Einlesen der erforderlichen Daten auf-

wendiger als bei den vorangegangenen Strategien. Die optimale Aufteilung von statischem

und dynamischem Anteil am SPM pro Prozess, wird aus der Losung der HAMP-Gleichungen


Abbildung 5.4: Adressen-Generierung fur HAMP

gewonnen. Ausgehend von diesen Daten, werden die dazugehorigen Speicherobjekte aus

einer Datei, die beim Losen der HAOP-Gleichungen erstellt wurde, ausgelesen. Die Großen

der Speicherobjekte, sind ebenfalls in einer separaten, beim Erstellen der HAOP-Gleichungen

erstellten, Datei abgelegt. Nachdem alle benotigten Informationen eingelesen und in entspre-

chenden internen Datenstrukturen abgelegt wurden, beginnt die Adressen-Generierung. Da-

bei wird mit dem statischen Teil des SPM begonnen. Die Adressen werden, beginnend mit

0x22000000, an die Speicherobjekte mosi,p, die fur den SAMP-Teil vorgesehen sind, ver-

geben. Wenn diese Speicherobjekte eine eindeutige Adresse zugeordnet bekommen ha-

ben, wird mit dem dynamischen Teil fortgefahren. Hier wird mit Adresse 0x22000000 +

∑p∈P ∑i∈Ip Ssi,p begonnen und die Adressvergabe, wie oben fur DAMP beschrieben, fortge-

setzt. Abbildung 5.4 veranschaulicht dieses Vorgehen.

5.1.5 cplex2header

cplex2header erstellt auf Basis der Ausgabe des addressGenerators die Datenstruktur, auf

die der SPMM zur Laufzeit zugreift, um zu eruieren, wann, welche Speicherobjekte, wohin

zu kopieren sind. Zudem wird die Profildatei ein weiteres Mal durchlaufen, um die maxima-

le Anzahl der Speicherobjekte festzustellen. Diese wird fur die interne Verwaltungsstruktur

des SPMM benotigt. Die Datenstruktur wird in Form einer C-Header Datei bereitgestellt, um

sie zusammen mit RTEMS, samt Erweiterung in Form des SPMM, und dem Benchmark zu

compilieren. Sie hat folgende Form:

/*

======================================================

SPM Assignment and Positioning for SAMP / DAMP / HAMP

======================================================

*/

#define MAX_MEM_OBJECTS <Max. Anzahl der Speicherobjekte>


unsigned int spmm_task_mo_list_0_dyn[] =

{

<Speicherobjekt_ID>, <Adresse>,

...

0xFFffFFff, 0xFFffFFff

};


{


...


};


{


...


};

unsigned int spmm_task_mo_list_stat[] =

{


...

0xFFffFFff

};

unsigned int* spmm_task_list[] =

{

&spmm_task_mo_list_stat[0],

&spmm_task_mo_list_0_dyn[0],

&spmm_task_mo_list_1_dyn[0],

&spmm_task_mo_list_2_dyn[0]

};

Diese Header-Datei realisiert, beispielhaft, eine SPM-Allokations-Strategie fur drei Prozesse.

Als erstes wird dem SPMM uber #define MAX MEM OBJECTS die maximale Anzahl der zu

verwaltenden Speicherobjekte bekannt gemacht. Danach schließt sich der dynamische Anteil

der Prozesse an. Es wird fur jeden, im Multiprozesssystem vorkommenden Prozess eine Liste

mit Speicherobjekten vorgehalten, die bei seiner Ausfuhrung in den SPM zu laden sind. Dazu


wird neben der Speicherobjekt-Identifikationsnummer, auch die Position innerhalb des SPM

abgelegt. ”0xFFffFFff, 0xFFffFFff“ kennzeichnet das Ende der Liste. Fur den stati-

schen Anteil des SPMs gibt es eine weitere Liste, in der die Speicherobjekte aller Prozesse

enthalten sind, welche in diesen Teil geladen werden sollen. Auch hier wird Speicherobjekt-

Identifikationsnummer und Adresse abgelegt. Hier dient 0xFFffFFff als Markierung fur das

Listenende. Abschließend wird ein Array mit Zeigern auf die einzelnen Listen angelegt.

Fur SAMP wird die Liste fur den statischen Teil des SPM vor dem Start des ersten Prozes-

ses einmal durchlaufen und somit alle Speicherobjekte in den SPM geladen. Bei der SPM-

Allokations-Strategie DAMP werden die Listen fur den dynamischen Teil, bei jedem Kontext-

wechsel durchlaufen. Als erstes die Liste des unterbrochenen Prozesses, um die Datenobjek-

te zuruck in den Hauptspeicher zu verschieben. Im Anschluss wird die Liste des einzulasteten

Prozesses durchlaufen, um die entsprechenden Speicherobjekte in den SPM zu verschieben.

Diese Listen sind fur SAMP zwar vorhanden, aber leer und werden nicht betrachtet. Im umge-

kehrten Fall ist die Liste fur den statischen Teil des SPM fur DAMP zwar vorhanden, aber leer.

Auch sie wird fur DAMP nicht durchlaufen. Ist HAMP als Allokations-Strategie ausgewahlt,

konnen beide Listenarten Eintrage vorhalten und werden somit auch zu den entsprechenden

Zeitpunkten betrachtet.

5.1.6 RTEMS Erweiterung

5.1.6.1 ScratchPad-Memory-Manager

Die Aufteilung des SPM durch die Prozesse selbst ist, wegen der gegenseitigen Abhangigkei-

ten, nicht sinnvoll. Da dem Betriebssystem alle Prozesse bekannt sind, wird sie durch einen

ScratchPad-Memory-Manager, kurz SPMM, realisiert. Die Verwaltung und Aktualisierung des

SPM, gemaß der verschiedenen Allokations-Strategien, werden uber diese Betriebssystemer-

weiterung umgesetzt.

Um die Speicherobjekte, entsprechend der zuvor festgelegten Datenstruktur, in den SPM ver-

schieben zu konnen, mussen diese dem SPMM bekannt gemacht werden. Dies wird mit Hilfe

einer weiteren Erweiterung des Betriebssystems, in der Initialisierungsphase, durchgefuhrt.

Dazu weiter unten mehr.

Zusatzliche Dereferenzierungsstufe

Um die Speicherobjekte der Prozesse verschieben zu konnen, mussen alle enthaltenden Zei-

ger auf diese Objekte angepasst werden. Diese Anpassung geschieht zur Laufzeit und wird

ebenfalls uber den SPMM verwirklicht. Die Benchmarks liegen als C-Datei vor. Da es in C/C++

keine Buchfuhrung uber die existierenden Zeiger gibt, ist es zur Laufzeit nicht moglich alle

Zeiger ausfindig zu machen. Daher wird eine zweite Dereferenzierungsstufe eingefuhrt. Die


Abbildung 5.5: Beispiel fur die zusatzliche Dereferenzierungsstufe eines Multiprozesssystems mitzwei Prozessen und der SPM-Allokations-Strategie DAMP

Programme durfen keine direkten Zeiger auf ihre Speicherobjekte verwenden. Diese werden

durch Zeiger auf SPMM-Objekte ersetzt. Sie bilden die zusatzliche Dereferenzierungsstufe

und zeigen auf die Speicherobjekte. Dies ist in Abbildung 5.5 fur ein Multiprozesssystem mit

zwei Prozessen und der SPM-Allokations-Strategie DAMP beispielhaft dargestellt. Die Spei-

cherobjekte konnen verschoben werden, ohne die Zeiger der Prozesse direkt anpassen zu

mussen. Lediglich die Zeiger der SPMM-Objekte werden umgebogen.

Schnittstellenbeschreibung

Der SPMM stellt den Anwendungsprogrammen eine API (Application Programming Interface)

zur Verfugung. Sie kann manuell, oder wie im Abschnitt 5.1.1 beschrieben, automatisiert,

verwendet werden. Bevor aber auf die API eingegangen wird, wird die grundlegende Daten-

struktur eines SPMM-Objektes vorgestellt.

Die SPMM-Objekte werden durch den Typ mem obj reprasentiert.

struct mem_obj

{

uint size;

uint profit;


task_id owner;

uint write_back;

void * cur_addr;

void * mm_addr;

<...>

};

Der Speicherbedarf des zu dem SPMM-Objekt gehorenden Speicherobjektes wird in size

gespeichert. Die Variable profit enthalt den Profit des Speicherobjektes. Um den zuge-

horigen Prozess identifizieren zu konnen, halt owner die entsprechende Id vor. In den SPM-

Allokationsstrategien DAMP und HAMP, werden beim Kontextwechsel nur Datenobjekte in den

SPM zuruckkopiert. Die Variable write back ist in diesem Fall 1 und sonst 0. Der Zeiger

cur addr zeigt immer auf die Adresse, an der sich das Speicherobjekt aktuell befindet. Im

Beispiel aus Abbildung 5.5 zeigen zum Zeitpunkt 0 alle Zeiger auf ihre Hauptspeicheradresse.

Wenn die Speicherobjekte dann, beim Auftreten eines Kontextwechsel, in den SPM kopiert

werden, zeigt cur addr auf die SPM-Adresse. Die Hauptspeicheradresse wird in mm addr

festgehalten. In dem Beispiel aus Abbildung 5.5 ist dies durch die Linien angedeutet. In dieser

Aufzahlung fehlt die zur Bildung der Verwaltungsstruktur des SPMM notigen Referenz. Auf

diese wird weiter unten eingegangen. Nun folgt die Beschreibung der API.

void spmm init(); Diese Funktion verschiebt die Kopierfunktion copy spm in den Scratch-

pad-Speicher. Der Platz dafur wurde im Vorfeld im SPM reserviert und bei der Realisierung der

Allokations-Strategien und der Adressberechnung berucksichtigt. Das Verschieben ist sinn-

voll, da die Kopierfunktion wenig Speicherplatz beansprucht und außerdem eine sehr hohe

Frequentierung aufweist. Zudem initialisiert spmm init die, vom SPMM benotigte, interne

Datenstruktur.

void copy spm(uint * src, uint * dest, uint len); Die Kopierfunktion kopiert die Speicher-

objekte vom Hauptspeicher in den SPM und vom SPM zuruck in den Hauptspeicher. Dabei

gibt len die Anzahl der zu kopierenden 32 Bit-Worte an. src ist der Quell- und dest der

Zielzeiger. Beim Kopieren werden Store-multiple- und Load-multiple-Befehle verwendet. Die-

se konnen bis zu acht Worte gleichzeitig verschieben.

void spglobal(mem obj * ptr); Die betrachteten globalen Speicherobjekte werden mit Hilfe

dieser Funktion dem SPMM bekannt gemacht. ptr zeigt auf das bereits existierende, an-

zumeldende SPMM-Objekt. Diese werden durch automatisierte Quelltexttransformation, mit

dem profitAnnotator, angelegt. spglobal wird vor dem Start der Prozesse, innerhalb der

Initialisierungsphase des Betriebssystems, aufgerufen.


void spdrop(task id id); Bei Terminierung eines Prozesses werden mit Hilfe dieser Funk-

tion alle Speicherobjekte des Prozesses id aus den Verwaltungsstrukturen des SPMM ge-

loscht und ihr Speicherplatz freigegeben.

void sptask(task id old task, task id new task); Da bei jedem Kontextwechsel der SPM

aktualisiert werden muss, ist es erforderlich den SPMM im Scheduler von RTEMS zu veran-

kern. Dies geschieht durch das Einfugen der Funktion sptask in die extensions table

von RTEMS:

rtems_extensions_table spmm_extensions_table =

{

NULL,

NULL,

NULL,

NULL,

sptask,

NULL,

NULL,

NULL

};

sptask wird also bei jedem Prozesswechsel aufgerufen. old task gibt dabei die Id des un-

terbrochenen Prozesses an und new task die des neu einzulastenden Prozesses. Diese In-

formationen sind wichtig, um das Verschieben der, zu den betroffenen Prozessen gehorenden,

Speicherobjekte mittels copy spm durchzufuhren.

Um einen reibungslosen Ablauf der Kontextwechsel und der damit verbundenen Aktualisie-

rung des SPM zu gewahrleisten, wird wahrend der Abarbeitung von sptask das Auftre-

ten von Interrupts unterbunden. In der Simulationsumgebung konnen Interrupts durch den

SWARM-Timer und den Interrupt-Controller auftreten. Der SWARM-Timer wird zur Realisie-

rung des RoundRobin-Schedules genutzt, um das Ende der Zeitscheibe zu signalisieren. Der

Interrupt-Controller wird nur fur Systeme mit mehreren Prozessoren verwendet und kommt

fur diese Arbeitsumgebung nicht als Interruptquelle in Frage. Der SWARM-Timer wird deak-

tiviert, indem ein Flag des Timers geloscht wird. Um diesen wieder zu aktivieren, muss der

entsprechende Flag wieder gesetzt werden.

Erweiterung der Prozesserzeugung

Um die Speicherobjekte der Prozesse automatisch, mit Hilfe der Funktion spglobal, beim

SPMM anmelden zu konnen, ist eine Erweiterung der Prozesserzeugung des Betriebssys-

tems erforderlich.


Dazu wird zur Compilezeit fur jeden Prozess ein task init block angelegt. Darin sind alle

Informationen enthalten, die RTEMS zur Verwaltung und zur Realisierung des RoundRobin-

Schedules benotigt. Zusatzlich wird ein Zeiger auf ein Feld von Zeigern auf alle Speicherob-

jekte des Prozesses angegeben.

In der Initialisierungsphase, wird am Ende der Startprozedur von RTEMS, die Funktion Init

aufgerufen. Diese weist sich zunachst die hochst mogliche Prioritat zu, um Unterbrechun-

gen zu vermeiden. Im Anschluss daran, wird spmm init aufgerufen, um den SPMM auf die

Verwendung der Prozesse vorzubereiten. Danach wird ein Feld durchlaufen, das fur jeden

Prozess einen Zeiger auf den dazugehorigen task init block enthalt. Entsprechend die-

ser Daten werden die Prozesse kreiert, die Speicherobjekte angemeldet und abschließend

der erste Prozess gestartet. RTEMS wendet dann automatisch das voreingestellte Schedule

an.

Um das Beenden der Prozesse zu vereinfachen, kann die Funktion stop task(task id

id) aufgerufen werden. Hier wird die Gesamtzahl der aktiven Prozesse verwaltet, so dass der

Simulationslauf beendet wird, sobald alle Prozesse terminiert sind. Außerdem ruft stop task

die Funktion spdrop auf.

Verwaltungsstruktur

Da durch die zur Compilezeit erstellten Listen, Abschnitt 5.1.5, die Adressen der Speicher-

Abbildung 5.6: Verwaltungsstruktur des SPMM

objekte feststehen und zur Laufzeit bei den, in dieser Arbeit verwendeten SPM-Allokations-

Strategien keine dynamisch erzeugten Objekte betrachtet werden, reicht zur Verwaltung eine

einfache Liste aus. Wie in Abbildung 5.6 dargestellt wird, halt der SPMM intern das Array

obj table vor. Hier werden Zeiger auf alle vorhandenen Speicherobjekte abgelegt. Die Da-

tenstruktur, welche die Speicherobjekte reprasentiert, wird um einen Eintrag erweitert:

struct mem_obj

{

<...>

uint mem_obj_ID

};


mem obj ID identifiziert die Speicherobjekte aller Prozesse eindeutig. Gleichzeitig zeigt es

auf den Eintrag in der obj table. Diese Liste bildet in der Umsetzung von SAMP, DAMP

und HAMP den Einstiegspunkt fur den Zugriff auf die Speicherobjekte.

5.1.6.2 Anpassungen von RTEMS und MPARM

Da in dieser Arbeit das Systemverhalten bei unterschiedlichen Zeitscheibenlangen betrachtet

werden soll, ist die genaue Konfigurierbarkeit dieser Große von großer Bedeutung. Die original

Versionen von MPARM und RTEMS genugten diesen Anspruchen nicht und mussten daher

dementsprechend angepasst werden. Im Folgenden wird zunachst die Problematik erlautert,

um dann auf die Losung einzugehen.

RTEMS

Standardmaßig wird die Zeitscheibenlange, wie in Kapitel 2.2.0.5 beschrieben, uber die Hea-

der-Datei confdefs.h determiniert. Folgende Makros sind fur die Definition der Zeitschei-

benlange verantwortlich:

#define CONFIGURE_MICROSECONDS_PER_TICK 1000 /* 1 millisecond */

#define CONFIGURE_TICKS_PER_TIMESLICE 50 /* 50 milliseconds */

Sie sind hier, exemplarisch, auf die Werte 1000 und 50 gesetzt. Das Makro CONFIGURE -

MICROSECONDS PER TICK konfiguriert den SWARM-Timer. In diesem Beispiel sendet er

alle 1000 µs einen Interrupt, der uber den Clock Manager, mit Hilfe der rtems clock tick

Direktive, RTEMS das Verstreichen eines Ticks mitteilt. Beim Auftreten des 50. Ticks (CONFI-

GURE TICKS PER TIMESLICE), wird ein Kontextwechsel durchgefuhrt. Das Problem dabei

Abbildung 5.7: Zeitpunkt der Konfiguration der Zeitscheibenlange (Standardmethode)

ist, dass der SWARM-Timer vor Beginn des Kontextwechsels gesetzt wird, so dass, wie in Ab-

bildung 5.7 dargestellt wird, der ganze Overhead mit in die Zeitscheibe des neuen Prozesses,

hier ist das Prozess 3, fallt. Der Overhead hangt aber vom zu sichernden und neu zu ladenden

Kontext der beteiligten Prozesse ab. Auch ist die Anzahl der zu kopierenden Speicherobjekte


nicht immer gleich groß. Die effektive Abarbeitungszeit fur die Prozesse kann somit schwan-

ken. Dies beeintrachtigt besonders bei kurzen Zeitscheibenlangen die Vorhersagbarkeit und

die Vergleichbarkeit der Ergebnisse. Die Granularitat, mit der RTEMS Zeitintervalle erfassen

kann, hangt von der Frequenz des Auftretens der Ticks ab. Mit jedem Tick ist ein Interrupt ver-

bunden, was negativen Einfluss auf die Gesamtperformance des Multiprozesssystems hat.

Abbildung 5.8: Zeitpunkt der Konfiguration der Zeitscheibenlange (Konfiguration des SWARM-Timersin sptask)

Fur die Realisierung des RoundRobin-Schedules wird die Anzahl der Ticks, bis ein Kontext-

wechsel durchgefuhrt wird, auf 1 gesetzt. So wird die Prozessausfuhrung nicht durch das

Auftreten von Interrupts verzogert. Bei jedem SWARM-Timer-Interrupt wird ein Prozesswech-

sel durchgefuhrt.

Eine erste Verbesserung, zur exakteren Konfigurierbarkeit der Zeitscheibenlange, stellt die

Verlagerung des erneuten Setzens der Zeitscheibenlange in die SPMM-Funktion sptask

dar. Sie wird nach dem Sichern und vor dem Laden des Kontextes aufgerufen. Wie in Ab-

bildung 5.8 dargestellt wird, werden die Register des Timers am Ende, also nachdem alle

Kopiervorgange abgeschlossen sind, neu konfiguriert. Nun hat nur das Laden des Kontextes

Einfluss auf die effektive Zeitscheibenlange des neu eingelasteten Prozesses. Um auch diese

Schwankung bei der Konfiguration der Zeitscheibenlange auszuschließen, ist eine Anpassung

von RTEMS erforderlich.

Das Ziel ist es, die Konfiguration des SWARM-Timers nach dem Laden des Kontextes, vor

der Ausfuhrung des Prozesses, durchzufuhren, wie es die Abbildung 5.9 visualisiert. Dazu

Abbildung 5.9: Zeitpunkt der Konfiguration der Zeitscheibenlange (Konfiguration des SWARM-Timersmit sptimerset)

wird, wie bei dem Einbinden von sptask, die Moglichkeit von RTEMS genutzt, User Ex-

tensions einzufugen. Die Datenstruktur, welche alle User Extensions verwaltet, wird um die

TASK BEGIN Extension erweitert:


rtems_extensions_table spmm_extensions_table =

{

NULL,

NULL,

NULL,

NULL,

sptask,

sptimerset,

NULL,

NULL

};

Der SPMM-API wird die Funktion sptimerset hinzugefugt. Sie konfiguriert den SWARM-

Timer entsprechend der eingestellten Zeitscheibenlange, indem sie direkt auf die Register

des Timers zugreift:

MEMORY_REG(SWARM_TIMER_MATCH0) = MEMORY_REG(SWARM_TIMER_CNT)

+ SPMM_CONFIGURE_TIMESLICE;

MEMORY REG(SWARM TIMER CNT) wird bei jedem Simulationsdurchlauf des SWARM-Ti-

mers um 1 inkrementiert. Wenn der Wert dieses Registers großer oder gleich dem Inhalt

von MEMORY REG(SWARM TIMER MATCH0) ist, wird ein Interrupt ausgelost und somit ein

Prozesswechsel durchgefuhrt. SPMM CONFIGURE TIMESLICE entspricht der zuvor festge-

legten Zeitscheibenlange, umgerechnet in Ticks.

Gemaß der Einsortierung in die obige struct, wird sptimerset vor Beginn der Ausfuhrung

der Prozesse ausgefuhrt. Der Problem besteht darin, dass nach RTEMS Definition, der Be-

ginn eines Prozesses, nicht bei jedem erneuten Aufruf, sondern nur einmal am Anfang der

Ausfuhrung existiert. Daher muss threaddispatch.c angepasst werden. Diese Datei fuhrt

das Sichern und Laden der Kontexte durch und ruft die TASK SWITCH Extension, in der vor-

liegenden Arbeit ist dies sptask, auf. threaddispatch.c wird so angepasst, dass nach

dem Laden des Kontextes sptimerset aufgerufen wird. So wird eine moglichst exakte und

von Schwankungen weitgehend freie Konfiguration der Zeitscheibenlange, wie in Abbildung

5.9 dargestellt, moglich.

MPARM

Da die Taktung des SWARM-Moduls bei Hauptspeicherzugriffen unterbrochen wird, zahlt der

SWARM-Timer wahrenddessen seine internen Register nicht hoch. D.h., dass sich die Zeit-

scheibe fur einen Prozess um die Zeit, welche fur Zugriffe auf den Hauptspeicher aufgewendet


wird, verlangert. Um diesen Overhead zu berucksichtigen, ist eine Anpassung des MPARM-

Simulators erforderlich.

Die Taktunterbrechung wird, wie in Kapitel 2.1.3 bereits erwahnt, durch Ausbleiben des Auf-

rufs der Cycle-Funktion des SystemC-Wrappers, hervorgerufen. Der Wrapper selbst wird

weiter getaktet. Daher wird er um den Prozess countpastcycles erweitert. Dieser Pro-

zess ist sensitiv auf positive Taktflanken und zahlt bei jeder Ausfuhrung einen 64 Bit Zahler

hoch.

Der Aufruf der Cycle-Funktion, welcher an den SWARM-Timer adressiert ist und somit einen

Simulationsdurchlauf des Timers hervorruft, wird durch die Funktion RTEMSCycle ersetzt.

Beim Aufruf der Cycle-Funktion, wird das interne Zahlregister MEMORY REG(SWARM TI-

Abbildung 5.10: Verlangerung der Zeitscheibe wegen atomarer Hauptspeicherzugriffe

MER CNT) des Timers nur um 1 erhoht. Die RTEMSCycle-Funktion erhoht das Zahlregister

um die, durch countpastcycles gezahlte Anzahl an Ticks. So wird auch die Zeit beruck-

sichtigt, die wahrend der Hauptspeicherzugriffe verstreicht.

Da Hauptspeicherzugriffe nicht unterbrochen werden (RTEMSCycle wird nach Ablauf eines

Hauptspeicherzugriffs aufgerufen), kann die Zeitscheibenlange um die Dauer eines solchen

Zugriffs langer sein als vorgesehen, wenn ein solcher Zugriff am Ende der Zeitscheibe auftritt.

Da sie maximal 0,01µs dauern, fallt diese Ungenauigkeit, auch bei sehr kleinen Zeitschei-

benlangen nicht ins Gewicht. Abbildung 5.10 verdeutlicht dies. Ohne die Anpassungen wurde

die Zeit jedes Hauptspeicherzugriffs vom SWARM-Timer nicht erfasst und somit die Zeitschei-

be verlangern.

5.1.7 XAMPopt

Wie bereits erwahnt, wird die abschließende Simulation mit Hilfe des MPARM-Simulators

durchgefuhrt. Dabei wird die Anzahl der Aufrufe aller Prozesse protokolliert. Diese Große

geht in die ILP-Gleichungen der SPM-Allokations-Strategien DAMP und HAMP ein, Kapitel

3, und beeinflusst den Profit der Speicherobjekte. In dem Simulationsdurchlauf, der die Pro-

fildatei erzeugt, sind keine Speicherobjekte im SPM. Nachdem die Allokations-Strategien zur

Anwendung gekommen sind, kann sich, sofern Speicherobjekte in den SPM verschoben wer-

den, die Laufzeit der Prozesse verkurzen. Somit sinkt die Anzahl der Aufrufe.

XAMPopt vergleicht die Anzahl der Aufrufe der abschließenden Simulation mit der Anzahl aus

5.2 Optimierung 65

der Profildatei. Wenn sich die Anzahl der Aufrufe verringert hat, wird die Profildatei so transfor-

miert, dass sie mit der geringeren Anzahl wieder als Eingabe fur die nachsten Arbeitsschritte

dienen kann. Dies wird solange wiederholt, bis keine Verringerung der Prozessaufrufe mehr

erreicht wird. Alternativ kann vom Nutzer eine Hochstgrenze der zu durchlaufenden Iteratio-

nen festgelegt werden.

In Kapitel 6.6 wird dieses Vorgehen, an Hand eines konkreten Beispiels, noch einmal ge-

nauer vorgestellt und auf die Verbesserungen, die sich in den einzelnen Iterationen ergeben,

eingegangen.

5.2 Optimierung

Das Ziel der Optimierung wurde bereits in Kapitel 4.2 hergeleitet und erlautert. Die Imple-

mentierung erfolgt auf zwei Arten. Zum Einen durch einen Bergsteiger-Algorithmus und zum

Anderen mit Hilfe von Simulated-Annealing. Der Bergsteiger-Algorithmus in der vorliegen-

den Form, bestimmt, sofern vorhanden, die optimale Zeitscheibenlange. Das Ergebnis von

Simulated-Annealing kann von dem Optimum abweichen.

Vor der Bestimmung der optimalen Zeitscheibenlange wird das Suchintervall eingegrenzt. Die

obere Grenze ergibt sich aus der maximal zulassigen Antwortzeit:

Q∗ (|P|−1)+CCS ∗ |P| ≤ RMPS (5.1)

Die untere Grenze ergibt sich durch den minimal zulassigen Anteil vom Overhead fur einen

Kontextwechsel an der Zeitscheibenlange:

100(Q+CCS)

∗CCS ≤ quota (5.2)

Diese Angaben konnen optional weggelassen werden. In dem Fall ergibt sich die obere Gren-

ze des Suchintervalles aus dem Maximum aller Ausfuhrungszeiten und die untere Grenze

wird auf 1 Zeiteinheit festgelegt.

Grundlage fur beide Implementierungen bildet das Laufzeitmodell aus Kapitel 4.3. Die Vor-

hersagbarkeit dieses Modells hangt sehr stark von den Ausfuhrungszeiten ab, die in Glei-

chung 4.7 eingehen. In dieser Arbeit wurden sie durch Simulation der einzelnen Prozes-

se mit dem MPARM-Simulator bestimmt. Dabei wurde von einer Speicherhierarchie ohne

SPM und ohne Cache ausgegangen. Die Zeitscheibenlange hat somit keinen Einfluss auf die

Ausfuhrungszeit der Prozesse selbst. Wie in Kapitel 4.1.2 gezeigt wurde, hat die Anwendung

der SPM-Allokations-Strategien keinen negativen Einfluss auf die Laufzeiten der Prozesse.

Wenn die Optimierung auf Basis dieser Laufzeiten der Prozesse einen Schedule ausgibt, in

dem alle Deadlines eingehalten werden, dann ist dies auch bei Anwendung von SAMP, DAMP

oder HAMP der Fall. Es handelt sich bei den Ausfuhrungszeiten also um pessimistisch ab-

geschatzte durchschnittliche Laufzeiten. Um die Worst-Case-Laufzeiten zu bestimmen, kann

das Tool aiT [WoC08] verwendet werden.


Die Bestimmung der optimalen Zeitscheibenlange wird zur Compilezeit durchgefuhrt. Die Op-

timierung lasst sich somit in dem Arbeitsablauf, der in Abbildung 5.1 dargestellt wird, noch vor

den profitAnnotator einreihen.

5.2.1 Bergsteigeralgorithmus

Der Bergsteigeralgorithmus bekommt, neben der Liste der Prozesse, uber die auf alle Pa-

rameter zugegriffen werden kann, und der Schrittweite (sp) auch das Zeitscheibenintervall

ubergeben.

Der Bergsteigeralgorithmus fangt bei der maximal zulassigen Zeitscheibenlange an nach ei-

ner zulassigen Losung zu suchen. Dabei wird die Zeitscheibenlange solange schrittweise

verringert, bis eine Lange erreicht wird, bei der alle Deadlines eingehalten werden. Der Algo-

rithmus sieht wie folgt aus:

int hillclimbing(map<int, task> * taskmap,

int Q, int minQ, int sp)

{

int deadlinetester = 0;

while ( (deadlinetester != 0)&&(Q != minQ) )

{

for ( int i=0; i < amountoftasks(taskmap); i++)

{

if (!((*taskmap)[i].d >= deadlineformula(taskmap, i, Q)))

{deadlinetester++;}

}

if ( Q-sp <= 0 )

{Q=1;}

else

{Q=Q-sp;}

}

if ((Q <= sp)&&(deadlinetester != 0))

{return 0;}

else

{return Q+sp;}

}

Zunachst wird die Zahlvariable deadlinetester mit 0 initialisiert. Diese gibt die Gesamt-

zahl der verpassten Deadlines an. Die while-Schleife wird solange durchlaufen, bis entwe-

5.2 Optimierung 67

der alle Prozesse ihre Deadlines einhalten oder die Zeitscheibenlange ihr vordefiniertes Mi-

nimum erreicht hat. Innerhalb der Schleife wird fur jeden Prozess, mit Hilfe der Funktion

deadlineformula, der Terminierungszeitpunkt bestimmt und mit der Deadline verglichen.

Wird sie nicht eingehalten, erhoht sich der deadlinetester. Nachdem alle Terminierungs-

zeitpunkte bestimmt worden sind, verringert sich die Zeitscheibenlange um die vorher festge-

legte Schrittweite. Wenn nach Beendigung der while-Schleife die Zeitscheibe kleiner ist als die

Schrittweite und mindestens ein Prozess seine Deadline nicht einhalt, wird 0 zuruckgegeben.

Sonst bildet die Zeitscheibenlange den Ruckgabewert. sp muss hier hinzu addiert werden,

da die Zeitscheibenlange, in der while-Schleife, bereits verringert wurde.

Da dieser Algorithmus bei der maximal zulassigen Zeitscheibenlange anfangt, alle Moglich-

keiten durchzuprobieren, und bei der ersten zulassigen Losung den Suchlauf stoppt, gibt er,

falls vorhanden, die optimale Zeitscheibenlange zuruck.

Die Worst-Case-Laufzeit diese Algorithmus hangt von den Ausfuhrungszeiten der Prozesse

ab. Wenn das Suchintervall, durch das Fehlen der Vorgaben Antwortzeit und Quota nicht ein-

geschrankt werden kann, und die Schrittweite sp auf 1 gesetzt wird, kann die while-Schleife

bis zu max∀p∈P(Cp) Schritte machen. Die Laufzeit eines Schleifendurchlaufes wird durch die

Funktion deadlineformula dominiert. Um den Terminierungspunkt eines Prozesses zu

bestimmen, werden, entsprechend der Funktion 4.7, die Funktionen 4.10 bis 4.12 ((⌊C�P /Q

⌋+

1) ∗ |P|)-mal aufgerufen und aufsummiert. C�P steht fur die durchschnittliche Ausfuhrungszeit

der Prozesse. Die Funktionen 4.10 bis 4.12 konnen alle in konstanter Zeit ausgewertet wer-

den. Um die Terminierungszeitpunkte aller Prozesse zu bestimmen, wird somit eine Laufzeit

von O(|P|2∗(C�P /Q)) erreicht. Zusammen mit der Worst-Case-Anzahl an Schleifendurchlaufen

ergibt sich fur den Bergsteigeralgorithmus eine WCET von O(|P|2 ∗ (C�P /Q)∗max∀p∈PCp).Diese WCET ist zwar polynomiell, kann aber durch lange Ausfuhrungszeiten der Prozesse

sehr groß werden. Die Anzahl der Prozesse ist typischerweise klein. Als Alternative zum Berg-

steigeralgorithmus dient ein Simulated Annealing- Algorithmus.

5.2.2 Simulated Annealing

Der Simulated Annealing- Algorithmus bekommt, genau wie der Bergsteigeralgorithmus, eine

Liste der Prozesse, mit den entsprechenden Parametern, wie Laufzeit und Deadline, uber-

geben. Neben dieser Liste, dient noch das Intervall, welches ggf. durch den Quota und die

Antwortzeit eingegrenzt ist, als Eingabe. Weitere Parameter, die Einfluss auf die Arbeitsweise

des Algorithmus haben, mussen bereitgestellt werden. Dazu weiter unten mehr.

Als Konfigurationen, die von dem Simulated Annealing- Algorithmus durchlaufen werden, die-

nen verschiedene Zeitscheibenlangen. Abbildung 5.11 zeigt den Zahlenstrahl, auf dem die un-

terschiedlichen Zeitscheibenlangen Q aufgetragen sind. Das zu durchsuchende Zeitscheiben-

intervall ist durch Min(Q) und Max(Q) eingeschrankt. Die Anfangskonfiguration wird zufallig

gewahlt.

Der Grundgedanke ist, dass bei hohen Temperaturen, die Anzahl und Hohe der Variation

starker ausfallt. So ist die Wahrscheinlichkeit sehr hoch, dass der Algorithmus nicht in loka-


Abbildung 5.11: Arbeitsweise des Simulated Annealing- Algorithmus fur die Zeitscheibenoptimierung

len Minima und Sattelpunkten stecken bleibt. Je weiter die Temperatur abgesenkt wird, umso

geringer fallen Anzahl und Hohe aus, sodass sich der Simulated Annealing- Algorithmus auf

eine bestimme Zeitscheibenlange einschwingt.

Die Variationsfunktion erhoht oder vermindert die aktuelle Konfiguration nach dem Zufalls-

prinzip. Die Hohe der Variation wird zufallig aus dem Intervall von Min(Q) und der aktuellen

Temperatur gewahlt.

Fur die Beurteilungsfunktion wird die Gesamtzahl der verpassten Deadlines der Prozesse

des Multiprozesssystems herangezogen. Dabei wird die Differenz zwischen der Anzahl der

verpassten Deadlines der alten Konfiguration und der Anzahl der verpassten Deadlines der

neuen Konfiguration zuruckgeben. Ist sie positiv so liegt eine Verbesserung vor. Um eine Ver-

schlechterung handelt es sich bei negativen Werten.

Wenn die Beurteilung der neu gewahlten Konfiguration eine Verbesserung ergibt, wird diese

sofort akzeptiert. Ist dies nicht der Fall, wird sie mit einer Wahrscheinlichkeit, die abhangig

von der Temperatur und der Große der Verschlechterung ist, ubernommen. Wenn die Beur-

teilungsfunktion keine Anderung der Gute zuruckgibt und die Zeitscheibenlange der neuen

Konfiguration uber der der alten Konfiguration liegt, wird sie, unabhangig von der Temperatur,

akzeptiert. Ist dies nicht der Fall, wird in einer dreistufigen Abschwachung, wie sie in Abbil-

dung 5.11 beschrieben ist, entschieden, ob die neue Konfiguration angenommen wird.

Nach [LAK97] hangt die Laufzeit und die Gute der Losung stark von dem ”Cooling Schedu-

le“ ab. Dieses gibt an, wie die Temperatur im Laufe des Algorithmus verringert wird. In die-

ser Arbeit sind drei Verschiedene implementiert. Das ”Cooling Schedule“ wird als Parameter

ubergeben. Dabei stehen folgende Funktionen zur Verfugung:

NeuesT (T ) = T −10 (5.3)

NeuesT (T ) =√

T (5.4)

NeuesT (T ) = T 0,95 (5.5)

5.2 Optimierung 69

Abbildung 5.12 visualisiert die Funktionen. Man erkennt hier gut, dass fur Funktion 5.3 am

meisten Iterationen durchlaufen werden und die Temperatur nur sehr langsam sinkt. Die Funk-

Abbildung 5.12: ”Cooling Schedule“: (a) Funktion 5.3 (b) Funktion 5.4 (c) Funktion 5.5

tion 5.4 fallt sehr schnell ab. Dadurch werden insgesamt auch am wenigsten Iterationen durch-

laufen. Funktion 5.5 stellt einen guten Kompromiss dar.

Die Starttemperatur muss vom Nutzer ubergeben werden. Außerdem kann zusatzlich eine

maximale Anzahl an Iterationen vorgegeben werden. Der Simulated Annealing- Algorithmus

terminiert, sobald die Temperatur den Wert 1 erreicht hat oder die maximale Anzahl an Itera-

tionen erreicht ist.

Die Laufzeit wird wieder durch das Laufzeitmodell bestimmt. Sie betrag O(|P|2 ∗ (C�P /Q)). Die

Anzahl der Aufrufe dieses Modells hangt von der Starttemperatur, der maximalen Anzahl an

Iterationen und dem ausgewahlten ”Cooling Schedule“ ab. Je hoher die Temperatur ist, um-

so ofter werden die Konfigurationen variiert und das Laufzeitmodell aufgerufen. Maximal liegt

diese Anzahl bei 0,5% der Temperatur und wird schrittweise auf 0,2% und 0,1% verringert.

Diese Werte haben sich durch empirische Tests als sinnvoll herausgestellt. Wenn das linea-

re ”Cooling Schedule“ (Funktion 5.3) ausgewahlt wird, die Starttemperatur der maximalen

Ausfuhrungszeit der Prozesse entspricht und die Anzahl der Iterationen nicht einschrankend

ist, kann kein Geschwindigkeitsvorteil im Vergleich zu dem Bergsteigeralgorithmus erzielt wer-

den. Die WCET wurde O(|P|2 ∗ (C�P /Q)∗o(T )∗O(T/1000)), wobei T der Starttemperatur ent-

spricht, betragen. Tests haben allerdings ergeben, dass eine Starttemperatur aureicht, die ein

Zehntel oder sogar ein Hundertstel der maximalen Ausfuhrungszeit der Prozesse entspricht.

Außerdem konnen mit der Funktion 5.5 Ergebnisse erzielt werden, die die gleich Gute haben

wie Durchlaufe, in denen die Funktion 5.3 als ”Cooling Schedule“ ausgewahlt wurde. Daraus

ergibt sich eine Laufzeit von O(|P|2 ∗ (C�P /Q)∗O(log(T ))∗O(T/1000)). Im Falle der Funktion

5.4 ergibt sich eine Laufzeit von O(|P|2∗(C�P /Q)∗O(T/1000)). Da auch fur sehr große Zahlen

die Temperatur nicht viel ofter als 10 mal verringert wird, kann diese durch einen konstanten

Parameter abgeschatz werden. Fur 3.9E+61 waren es 8 Verkleinerungen. Durch das Vorge-

ben einer maximalen Anzahl an Iterationen, kann die Anzahl der Aufrufe des Laufzeitmodells

weiter eingeschrankt werden. Der Geschwindigkeitsgewinn wird zu Lasten der Gute des Er-

gebnisses erzielt.

Die Anwendung von Simulated Annealing bring also vor allem fur Multiprozesssysteme mit

langen Laufzeiten einen Geschwindigkeitsvorteil, sofern die entsprechenden Parameter aus-


gewahlt werden. Ein weiterer Vorteil dieser Art der Optimierung liegt darin, dass, im Gegen-

satz zum Bergsteigeralgorithmus, hier wird im Fall, dass kein Schedule moglich ist, die Start-

konfiguration zuruckgegeben, eine Konfiguration zuruckgegeben wird, in der moglichst wenige

Deadlines verpasst werden.

6 Ergebnisse 71

Kapitel 6

Ergebnisse

In den folgenden Unterkapiteln werden zunachst die betrachteten Benchmarks beschrieben

um im Anschluss den Einfluss der Zeitscheibenlange auf Scratchpad-basierte Systeme (Ab-

schnitt 6.2), den, durch die SPM-Allokations-Strategien DAMP und HAMP erzeugten Over-

head (Abschnitt 6.3) und den Einfluss der Zeitscheibenlange auf Cache-basierte Systeme

(Abschnitt 6.4) zu analysieren. Dabei stehen der Energieverbrauch und die Laufzeit im Fo-

kus des Interesses. Da fur SAMP keine Kopierkosten anfallen, wird der Overhead dieser

Allokations-Strategie nicht betrachtet. Fur die Cache-basierten Multiprozesssysteme werden

zudem die Cache-Misses bei unterschiedlichen Zeitscheibenlangen analysiert. Der Abschnitt

6.5 stellt Cache- und Scratchpad- basierte Systeme gegenuber. Im letzten Abschnitt (Ab-

schnitt 6.7) wird die in Kapitel 4.2 vorgestellte Optimierung auf die Benchmarks angewendet

und das Ergebnis verifiziert.

Das betrachtete Zeitscheibenlangen-Intervall liegt zwischen 0,05ms und 4,00ms. Dies wur-

de aufgrund der Laufzeiten der Benchmarks ausgewahlt. Bei einer Zeitscheibenlange von

4,00ms weisen die meisten Prozesse ca. 3 bis 4 Aufrufe auf. Außerdem sind die Abstande der

betrachteten Zeitscheibenlangen im Intervall von 1,00ms bis 4,00ms relativ groß gewahlt, da

bei langen Zeitscheiben die Auswirkungen der Zeitscheibenlange auf das Multiprozesssystem

geringer sind.

Insgesamt wurden in diesem Intervall 12 verschiedene Zeitscheibenlangen betrachtet. Da-

bei wurden SPMs und Caches mit den Speichergroßen 256B, 512B, 1kB, 2kB, 4kB, 8kB

und 16kB, die SPM-Allokations-Strategien SAMP, DAMP und HAMP, unterschiedliche Cache-

Assoziativitaten und ”uniformed“-Caches und ”split“-Caches, betrachtet. ”Uniformed“-Caches

werden in diesem Kapitel auch als UNI-Caches bezeichnet und ”split“-Caches als SPLIT-

Caches.

In den folgenden Abschnitten werden zunachst anhand einiger reprasentativer Beispiele der

drei Benchmarks der jeweilige Aspekt analysiert. Im letzen Teil der Abschnitte werden die Er-

gebnisse zusammengefasst. Dabei werden auch die Daten berucksichtigt, die nicht explizit in

dieser Arbeit vorgestellt werden.

72 6 Ergebnisse

6.1 Beschreibung der Benchmarks

Die, in der vorliegenden Arbeit analysierten Benchmarks sind in drei Themengebiete unter-

gliedert und weisen verschiedene Eigenschaften, wie Anzahl und Laufzeit der Prozesse, auf.

Auch unterscheiden sie sich in der Menge und Große der Speicherobjekte in den Prozessen.

Die Tabelle 6.1 gibt einen Uberblick uber die Eigenschaften der Benchmarks. Es werden zum

Name LaufzeitSIM / WCET [ms]

Art & Große der Speicherobjekte

IndustrialSelectionsort 40,242 / 233,000 2 Befehlsobj. (4B - 124B),

1 Datenobj. (1200B)StateChart 33,140 / 45,821 8 Befehlsobj. (492B - 2692B),

22 Datenobj. (4B - 64B)Edgedetection 30,160 / 72,193 7 Befehlsobj. (4B - 356B),

9 Datenobj. (32B - 1280B)

Mobile-Devicemd5 210,030 / 4264,000 15 Befehlsobj. (16B - 3056B), 1 Date-

nobj (64B)jfdctint 0,574 / 0,588 2 Befehlsobj. (64B - 1564B),

1 Datenobj. (256B)g723 encode 57,825 / 176,000 15 Befehltsobj. (12B - 1152B),

5 Datenobj. (64B - 1024B)g723 decode 46,591 / 74,335 13 Befehlsobj. (44B - 172B),


Telecommunication-DSPiir-filter 4,766 / 11,261 2 Befehlsobj (68B - 128B),

1 Datenobj (80B)Hamming Window 13,307 / 41,011 1 Befehlsobj. (124B),

3 Datenobj. (160B - 1764B)fdct 24,083 / 43,973 2 Befehlsobj. (32B - 1124B),

1 Datenobj. (256B)adpcm decode 26,402 / 53,586 12 Befehlsobj (8B - 1692B),

72 Datenobj. (4B - 256B)adpcm encode 27,734 / 69,207 15 Befehlsobj. (8B - 1716B),


Tabelle 6.1: Ubersicht der Benchmarks

Einen die mit MPARM simulierten Laufzeiten angegeben und zum Anderen die WCETs (Worst

Case Execution Time). Diese wurden mit dem Tool ait [WoC08] ermittelt. Die Laufzeiten ge-

hen in die, in Abschnitt 6.7 durchgefuhrten, Optimierung ein.

Der Benchmark ”Industrial“ besteht aus den Programmen ”Selectionsort“, ”StateChart“ und

”Edgedetection“. ”StateChart“ ist der Quellcode einer Fensterhebersteuerung, der mit einem

Zustandsautomaten realisiert ist. ”Edgedetection“ wird in der automatischen Bilderkennung

eingesetzt und ”Selectionsort“ ist die Implementierung des bekannten Sortieralgorithmuses.

6.2 Verhalten Scratchpad-basierter Systeme bei unterschiedlichen Zeitscheibenlangen 73

Die simulierten Laufzeiten der Prozesse unterscheiden sich nicht sehr stark, wodurch die Ter-

minierungszeitpunkte nahe beieinander liegen. Der Speicherbedarf, der potenziell in den SPM

verschiebbaren Speicherobjekte, liegt zwischen 4B und 1,3 kB.

”Mobile Device“ stellt eine weitere Gruppierung von Prozessen zu einem Benchmark dar.

Dieser besteht aus insgesamt 4 Prozessen. ”md5“ (”Message-Digest Algorithm 5“) ist eine

verbreitete kryptographische Hash-Funktion. ”jfdctint“ stellt eine Implementierung der diskre-

ten Cosinus-Transformation dar und wird bei der Umwandlung von Bildern ins JPEG-Format

eingesetzt. Die Prozesse ”g723 encode“ und ”g723 decode“ sind Sprach-Codecs, die sich

durch eine sehr geringe Datenrate auszeichnen. Die Bandbreite der Große der Speicherob-

jekte reicht von 4B bis hin zu uber 4kB großen Objekten. Die Laufzeiten der Prozesse un-

terscheiden sich starker als bei den beiden anderen Benchmarks. Das fuhrt dazu, dass die

Terminierungszeitpunkte stark differieren. Dies kann in realen Multiprozesssystemen vorkom-

men und soll auf diese Weise bei der Analyse berucksichtigt werden.

Der Benchmark ”Telecommunication-DSP“ besteht aus 5 Prozessen. ”iir-filter“ (infinite impulse

response filter) ist ein Filtertyp, der in der digitalen Signalverarbeitung angewendet wird. ”Ham-

ming Window“ findet, in Verbindung mit der FFT (Fast Fourier Transformation), in der Spektral-

analyse Anwendung. ”fdct“ ist eine Umsetzung der schnellen diskreten Fouriertransformation.

”adpcm“ (adaptive differential pulse code modulation) ist eine Komprimierungsmethode fur

Audiosignale. Die Großen der Speicherobjekte liegen bei diesem Benchmark zwischen 4B

und 1,8kB. Die Laufzeiten der Prozesse liegen relativ eng beieinander.

6.2 Verhalten Scratchpad-basierter Systeme bei unterschiedlichen

Zeitscheibenlangen

6.2.1 Industrial Benchmark

Abbildung 6.1: Energiebedarf bei verschie-denen Zeitscheibenlangen des IndustrialBenchmarks, SPM-Große: 16kB

Abbildung 6.2: Energiebedarf bei verschie-denen Zeitscheibenlangen des IndustrialBenchmarks, SPM-Große: 256B

Die Abbildungen 6.1 bis 6.4 stellen den Energiebedarf und das Laufzeitverhalten fur die SPM-

Allokations-Strategien SAMP, DAMP und HAMP des Industrial Benchmarks bei verschiede-

nen Zeitscheibenlangen, fur die SPM-Großen 16kB und 256B, dar.

74 6 Ergebnisse

Abbildung 6.3: Laufzeitverhalten bei ver-schiedenen Zeitscheibenlangen des IndustrialBenchmarks, SPM-Große: 16kB

Abbildung 6.4: Laufzeitverhalten bei ver-schiedenen Zeitscheibenlangen des IndustrialBenchmarks, SPM-Große: 256B

Der Energiebedarf und das Laufzeitverhalten korrelieren sehr stark. Dies lasst sich dadurch

erklaren, dass Speicherobjekte im SPM nicht nur positiven Einfluss auf den Energiebedarf ha-

ben, sondern auch auf die Speicherzugriffszeiten und somit auf die Laufzeit des Gesamtsys-

tems. Dieser Zusammenhang wurde bereits in Kapitel 4.2 naher erlautert und ist grundlegend

fur die Optimierung.

Ein weiterer Aspekt, welcher der Optimierung zu Grunde liegt, in These 4.1.1 ausformuliert

und im anschließenden Absatz bewiesen wird, bestatigt sich in den Abbildungen 6.1 bis 6.4.

Mit zunehmender Zeitscheibenlange sinkt der Energiebedarf und die Laufzeit des Gesamt-

systems. Dies gilt fur SAMP, DAMP und HAMP, sowohl fur den SPM der Große 16kB, als

auch fur den SPM der Große 256B.

SAMP weist fur den 16kB großen SPM, bei allen betrachteten Zeitscheibenlangen, eine bes-

sere Energieeffizienz als DAMP auf. Der Industrial Benchmark hat insgesamt nur drei Pro-

zesse, so dass alle Speicherobjekte in den großen SPM verschoben werden konnen. Da

fur SAMP keine Kopierkosten bei Kontextwechsel auftreten und durch das Verschieben aller

Speicherobjekte in den SPM der Laufzeit- und Energiebedarf der Prozesse sehr gering gehal-

ten wird, haben auch sehr kurze Zeitscheibenlangen von 0,05ms nur geringen Einfluss. DAMP

kann den Vorteil nicht ausnutzen, potenziell mehr Speicherobjekte in den SPM verschieben

zu konnen. Die Nachteile machen sich, bei dem 16kB großen SPM, in diesem Beispiel fur

kurze Zeitschenlangen deutlich. Je kurzer die Zeitscheibenlange, desto mehr Kontextwechsel

fallen an. Dadurch verringert sich der Profit der Speicherobjekte und es konnen weniger Ob-

jekte in den SPM verschoben werden. Dies hat negativen Einfluss auf die Energie- und Lauf-

zeiteffizienz. So weist DAMP bei einer Zeitscheibenlange von 0,05ms einen 6-mal hoheren

Energiebedarf auf als SAMP. Es ist zu beachten, dass, auch wenn keine Speicherobjekte in

den SPM verschoben werden, ein gewisser Overhead fur die Kontextwechsel anfallt. Bei sehr

kurzen Zeitscheibenlangen ist die Anzahl der Wechsel sehr hoch. So lassen sich diese ex-

tremen Unterschiede begrunden. HAMP weist eine ebenso gute Effizienz wie SAMP auf. Der

dynamische Teil des SPM ist, bei allen Zeitscheibenlangen, fur den 16kB großen SPM leer.

Bei dem SPM der Große 256B konnen nicht alle Speicherobjekte in den SPM bei Anwen-

dung der Allokations-Strategie SAMP ausgelagert werden. Dadurch steigt der Laufzeit- und

Energiebedarf fur SAMP an. Fur die Zeitscheibenlangen 0,05ms bis 0,20ms ist die Anzahl


der Kontextwechsel und somit auch die Hohe der Kopierkosten so hoch, dass SAMP DAMP

dennoch vorzuziehen ist. Fur die Zeitscheibenlangen 0,30ms bis 4,00ms ist DAMP SAMP vor-

zuziehen. Der Vorteil, dass der komplette SPM den Prozessen zur Verfugung gestellt wird,

zeigt hier Wirkung. Fur die Zeitscheibenlangen 0,50ms bis 4,00ms ist HAMP durchschnittlich

um 1% besser als DAMP und um 5% besser als SAMP. Tabellen 6.2 und 6.3 stellen die pro-

zentualen Verbesserungen, die sich fur SAMP, DAMP und HAMP in dem Zeitscheibenintervall

von 0,05ms bis 4,00ms fur die betrachteten Scratchpad-Großen ergeben, gegenuber.

Diese Gegenuberstellung zeigt auch, dass die Speicherkapazitat großen Einfluss auf Energie-

Allok.-Strategie

proz. VerbesserungEnergie / Laufz.

SAMP 34% / 50%DAMP 89% / 93%HAMP 34% / 50%

Tabelle 6.2: Prozentuale Verbesserungder SPM-Allokations-Strategien, SPM-Große: 16kB (Industrial B.)

Allok.-Strategie


SAMP 63% / 64%DAMP 66% / 67%HAMP 66% / 67%

Tabelle 6.3: Prozentuale Verbesserungder SPM-Allokations-Strategien, SPM-Große: 256B (Industrial B.)

und Laufzeiteffizienz haben kann. So ist fur DAMP, bei einer Zeitscheibenlange von 0,05ms

ein SPM mit der Große 256B besser geeignet als ein SPM mit der Große 16kB. In diesem Fall

wird der 16kB große SPM nicht vollstandig ausgenutzt und verursacht, aufgrund der hoheren

Speicherkapazitat, einen hoheren Energiebedarf. Hinzu kommt, dass aufgrund des hoheren

Energieverbrauchs des großeren SPM, weniger Speicherobjekte profitabel in den SPM ver-

schoben werden konnen.

6.2.2 Mobile Device Benchmark

Die Abbildungen 6.5 bis 6.8 stellen den Energiebedarf und das Laufzeitverhalten fur die SPM-

Allokations-Strategien SAMP, DAMP und HAMP des Mobile Device Benchmarks bei verschie-

denen Zeitscheibenlangen, fur die SPM-Großen 16kB und 256B, dar.

Im Vergleich zum Industrial Benchmark ist der Energie- und Laufzeitbedarf hoher. Dies liegt an

der großeren Anzahl und an den langeren Laufzeiten der Prozesse. Die These 4.1.1 bestatigt

sich auch in diesem Beispiel.

Aufgrund der hohen Zahl an Speicherobjekten, ist der SPM zu klein um alle Speicherobjek-

te aufzunehmen. Daher ist die Differenz des Energie- und Laufzeitbedarfs zwischen SAMP

und DAMP kleiner als bei dem Industrial Benchmark. Die Verbesserungen, die durch das

Vergroßern der Zeitscheibenlange erzielt werden konnen, sind dadurch bei dem Industrial

Benchmark starker ausgepragt. Tabellen 6.4 und 6.5 stellen die Verbesserungen, die sich fur

SAMP, DAMP und HAMP in dem Zeitscheibenintervall von 0,05ms bis 4,00ms fur die betrach-

teten Scratchpad-Großen ergeben, gegenuber. Mit DAMP konnen insgesamt mehr Speicher-

objekte ausgelagert werden. Dieser Vorteil kommt bei dem Mobile Device Benchmark etwas

besser zur Geltung. Fur den Scratchpad mit der Große 16kB ist SAMP DAMP dennoch fur

76 6 Ergebnisse

Abbildung 6.5: Energiebedarf bei verschie-denen Zeitscheibenlangen des Mobile-DeviceBenchmarks, SPM-Große: 16kB

Abbildung 6.6: Energiebedarf bei verschie-denen Zeitscheibenlangen des Mobile-DeviceBenchmarks, SPM-Große: 256B

Abbildung 6.7: Laufzeitverhalten bei ver-schiedenen Zeitscheibenlangen des Mobile-Device Benchmarks, SPM-Große: 16kB

Abbildung 6.8: Laufzeitverhalten bei ver-schiedenen Zeitscheibenlangen des Mobile-Device Benchmarks, SPM-Große: 256B

alle betrachteten Zeitscheibenlangen vorzuziehen. Die Differenz des Laufzeit- und Energie-

bedarfs hat sich im Vergleich zum Industrial Benchmark aber stark verringert. HAMP weist fur

den SPM mit der Große 16kB nie einen großeren Energie- und Laufzeitbedarf auf als SAMP.

Fur die Zeitscheibenlangen 1,00ms, 2,50ms und 4,00ms liegt der Energie- und Laufzeitbedarf

sogar 2% unter den Verbrauchen von SAMP.

Fur den 256B großen SPM ist in dem Intervall von 1,00ms bis 4,00ms DAMP besser als SAMP.

DAMP verbraucht hier ca. 1% weniger Energie als SAMP. Fur die Zeitscheibenlangen 0,20ms

und 0,30ms liegt der Energie- und Laufzeitbedarf von HAMP zwischen dem von SAMP und

DAMP. HAMP ist ca. 1% schlechter als SAMP. Dies lasst sich mit kleinen Ungenauigkeiten in

der Voranalyse der Kopierkosten begrunden. Die Kopierkosten, die in die ILPs eingehen, sind

Allok.-Strategie


SAMP 57% / 62%DAMP 76% / 81%HAMP 57% / 62%

Tabelle 6.4: Prozentuale Verbesserungder SPM-Allokations-Strategien, SPM-Große: 16kB (Mobile Device B.)

Allok.-Strategie


SAMP 57% / 58%DAMP 61% / 61%HAMP 58% / 58%

Tabelle 6.5: Prozentuale Verbesserungder SPM-Allokations-Strategien, SPM-Große: 256B (Mobile Device B.)


etwas geringer, als in der abschließenden Simulation. Dadurch kann es vorkommen, dass

fur HAMP zuviele Speicherobjekte in den dynamischen Part des SPM allokiert werden. Die

starkste beobachtete negative Abweichung von HAMP betragt gegenuber der, bezuglich des

Energie- und Laufzeitbedarfs besseren SPM-Allokations-Strategie SAMP oder DAMP, 2%. Im

Abschnitt 6.2.4 wird deutlich, dass dies die Ausnahme ist. Der großte, gemessene, prozen-

tuale Vorteil von HAMP liegt bei 10%.

6.2.3 Telecommunication-DSP Benchmark

Die Abbildungen 6.9 bis 6.12 stellen den Energiebedarf und das Laufzeitverhalten fur die

SPM-Allokations-Strategien SAMP, DAMP und HAMP des Telecommunication-DSP Bench-

marks bei verschiedenen Zeitscheibenlangen, fur die SPM-Großen 16kB und 256B, dar.

Abbildung 6.9: Energiebedarf bei verschie-denen Zeitscheibenlangen des Telecom.-DSPBenchmarks, SPM-Große: 16kB

Abbildung 6.10: Energiebedarf bei verschie-denen Zeitscheibenlangen des Telecom.-DSPBenchmarks, SPM-Große: 256B

Abbildung 6.11: Laufzeitverhalten beiverschiedenen Zeitscheibenlangen desTelecom.-DSP Benchmarks, SPM-Große:16kB

Abbildung 6.12: Laufzeitverhalten beiverschiedenen Zeitscheibenlangen desTelecom.-DSP Benchmarks, SPM-Große:256B

Fur diesen Benchmark ergibt sich ein sehr ahnliches Bild wie bei den Vorangegangenen.

Die These 4.1.1 wird auch hier untermauert. Die Tabellen 6.6 und 6.7 stellen die Verbes-

serungen dar, die sich bei der Verlangerung der Zeitscheibenlangen fur die einzelnen SPM-

Allokations-Strategien ergeben. Zu beachten ist, dass diese Verbesserung nur ein Indikator

fur den Grad der Beeinflussung der Allokations-Strategie durch die Zeitscheibenlange ist. Die-

se sagt nichts uber die Gute der SPM-Belegung in Bezug auf Energie und Laufzeit aus. Der

78 6 Ergebnisse

Allok.-Strategie


SAMP 58% / 63%DAMP 81% / 85%HAMP 58% / 63%

Tabelle 6.6: Prozentuale Verbesserungder SPM-Allokations-Strategien, SPM-Große: 16kB (Telecom.-DSP B.)

Allok.-Strategie


SAMP 65% / 65%DAMP 66% / 66%HAMP 66% / 66%

Tabelle 6.7: Prozentuale Verbesserungder SPM-Allokations-Strategien, SPM-Große: 256B (Telecom.-DSP B.)

Telekommunication-DSP Benchmark weist, trotz der großten Anzahl an Prozessen, nicht die

langste Laufzeit auf. Dadurch liegt der Energie- und Laufzeitbedarf dieses Benchmarks zwi-

schen den der beiden vorangegangenen Benchmarks.

6.2.4 Zusammenfassung

Die Abbildungen 6.13 und 6.14 visualisieren den durchschnittlichen Energieverbrauch und

das durchschnittliche Laufzeitverhalten fur die SPM-Allokations-Strategien SAMP, DAMP und

HAMP. Dabei wurde uber alle SPM-Großen und uber alle Benchmarks gemittelt. Deutlich wird

Abbildung 6.13: Durchschnittlicher Ener-gieverbrauch bei verschiedenen Zeitschei-benlangen

Abbildung 6.14: Durchschnittliches Lauf-zeitverhalten bei verschiedenen Zeitschei-benlangen

die starke Korrelation der Kurven fur den Energieverbrauch und das Laufzeitverhalten. Insge-

samt lasst sich festhalten, dass fur sehr kurze Zeitscheibenlangen SAMP gegenuber DAMP

vorzuziehen ist. Erst ab einer Lange von 1,00ms liegt der Enegiebedarf und auch die Lauf-

zeit von DAMP unter dem von SAMP. Dieses Verhaltnis sollte sich nicht wieder umkehren, da

bei weiterer Verlangerung der Zeitscheibenlange alle betrachteten Prozesse mit einem Aufruf

auskommen wurden. Somit ergeben sich keine Veranderungen fur die Laufzeit und den Ener-

gieverbrauch, da die Zeitscheibe fruhzeitig unterbrochen wird, wenn diese nicht ausgenutzt


wird. HAMP ist im Durchschnitt uber alle betrachteten Zeitscheibenlangen die beste SPM-

Allokations-Strategie. Dies geht aus den Abbildungen nicht deutlich hervor. In dem Intervall

von 0,05ms bis 0,50ms weist HAMP durchschnittlich eine um 1% kurzere Laufzeit und einen

um 1% niedrigeren Energieverbrauch auf als SAMP. Ab einer Zeitscheibenlange von 1,00ms

wachst der Vorteil von HAMP gegenuber der nachstbesten SPM-Allokations-Strategie, ab

1,00ms ist dies DAMP, auf 3% an.

Die Tabelle 6.8 gibt die durchschnittlichen Verbesserungen der einzelnen Allokations-Strate-

Allok.-Strategie proz. VerbesserungEnergie / Laufz.

SAMP 59% / 61%DAMP 71% / 76%HAMP 62% / 64%

Tabelle 6.8: Durchschnittliche prozentuale Verbesserung der SPM-Allokations-Strategien

gien, gemittelt uber alle SPM-Großen und Benchmarks, an, welche sich in dem Zeitschei-

benlangen-Intervall von 0,05ms bis 4,00ms ergeben. Die Beeinflussung der Laufzeit und des

Energieverbrauchs durch die Zeitscheibenlange liegen sehr nah beieinander. Dieses Ergebnis

deckt sich mit den sehr ahnlichen Kurvenverlaufen in den Abbildungen 6.13 und 6.14. Erwar-

tungsgemaß wird SAMP am geringsten von der Zeitscheibenlange beinflusst. Mit rund 60%

ist der Einfluss der Zeitschenlange dennoch sehr groß. DAMP weist eine ca. 15% starkere

Wechselwirkung auf als SAMP. Der Einfluss auf die SPM-Allokations-Strategie HAMP liegt

nur geringfugig uber der von SAMP. Die hohere Beeinflussung lasst sich durch den dynami-

schen Anteil von HAMP erklaren.

Das Teilfazit(a) bezieht sich auf die SPM-Allokations-Strategie DAMP und das Zeitscheiben-

langen-Intervall von 0,05ms bis 0,50ms. Hier kann die starkste Beeinflussung aller SPM-

Allokations-Strategien beobachtet werden.

Teilfazit (a):

Eine Verlangerung der Zeitscheibenlange von 10% kann eine bis zu 65% kurzere Laufzeit und

einen bis zu 60% geringeren Energieverbrauch fur ein Multiprozesssystem mit SPM zur Folge

haben.

Teilfazit (b):

Grundsatzlich ist bei kurzen Zeitscheibenlangen die SPM-Allokations-Strategie SAMP der

Strategie DAMP vorzuziehen. HAMP weist fur alle Zeitscheibenlangen eine sehr gute Laufzeit-

und Energieeffizienz auf.

80 6 Ergebnisse

6.3 Einfluss des Overheads auf die SPM-Allokations-Strategien

DAMP und HAMP


Die Abbildungen 6.15 bis 6.18 stellen den Energie- und Laufzeitbedarf fur verschiedene Zeit-

scheibenlangen dar, welcher durch die, von den SPM-Allokations-Strategien DAMP und HAMP

hervorgerufenen Kopiervorgange, wahrend der Kontextwechsel, entsteht. Dabei werden wie-

der die SPM-Großen 16kB und 256B visualisiert. Grundsatzlich lasst sich eine starke Kor-

Abbildung 6.15: Energie-Overhead bei ver-schiedenen Zeitscheibenlangen des IndustrialBenchmarks, SPM-Große: 16kB

Abbildung 6.16: Energie-Overhead bei ver-schiedenen Zeitscheibenlangen des IndustrialBenchmarks, SPM-Große: 256B

Abbildung 6.17: Laufzeit-Overhead bei ver-schiedenen Zeitscheibenlangen des IndustrialBenchmarks, SPM-Große: 16kB

Abbildung 6.18: Laufzeit-Overhead bei ver-schiedenen Zeitscheibenlangen des IndustrialBenchmarks, SPM-Große: 256B

relation zwischen Energieverbrauch und Laufzeit feststellen. Außerdem verursachen kurze

Zeitscheibenlangen, im Allgemeinen, einen hoheren Verbauch als lange Zeitscheibenlangen.

Fur den SPM der Große 16kB fallt bei der SPM-Allokations-Strategie DAMP auf, dass fur die

Zeitscheibenlange von 0,30ms der Energie- und Laufzeitbedarf ansteigt, bevor er ab der Zeit-

scheibenlange 0,50ms wieder sinkt. Dies kann ebenfalls fur den 256B großen SPM fur HAMP

bei der Zeitscheibenlange 0,50ms, in abgeschwachter Form, beobachtet werden. Ein hoherer

Energieverbrauch bzw. eine langere Laufzeit fur den Overhead bedeutet jedoch nicht, dass

auch der Energie- und Laufzeitbedarf des Gesamtsystems ansteigt. Dies belegen die Abbil-

dungen 6.1 bis 6.4, in denen der Verbrauch des Gesamtsystems fur den Industrial Bench-

mark visualisiert werden. In die ILP-Gleichungen fur die SPM-Allokations-Strategien DAMP

und HAMP, Kapitel 3, gehen die Kopierkosten der Speicherobjekte und die Anzahl der Kopier-

6.3 Einfluss des Overheads auf die SPM-Allokations-Strategien DAMP und HAMP 81

vorgange ein. Bei kurzen Zeitscheiben, ist die Anzahl der Kopiervorgange hoher als bei langen

Zeitscheiben. Dadurch verringert sich die Auswahl der potenziell in den SPM verschiebba-

ren Speicherobjekte. Dies wurde bereits in Kapitel 4.2 erlautert. Bei der Allokations-Strategie

DAMP konnen, fur den Industrial Benchmark, ab der Zeitscheibenlange 0,30ms wieder eine

gewissen Anzahl an Speicherobjekten mehr profitabel, im Hinblick auf den Energieverbrauch,

in den SPM verschoben werden. Dadurch steigen zwar die Kopierkosten, dies aber zu Guns-

ten geringerer Verbrauche des Gesamtsystems. Das Gleiche gilt fur den 256B-SPM, der Zeit-

scheibenlange 0,50ms und der SPM-Allokations-Strategie HAMP.

Der prozentuale Anteil des, durch die Kopiervorgange hervorgerufenen Overheads am Ener-

gie- und Laufzeitbedarf des Gesamtsystems liegt im Durchschnitt fur den Industrial-Bench-

mark bei 2,5% und uberschreitet nie die 8% Marke.


Die Abbildungen 6.19 bis 6.22 visualisieren die Energie- und Laufzeitbedarfe des Mobile De-

vice Benchmarks, welche durch die Kopiervorgange wahrend der Kontextwechsel, bei den

SPM-Allokationsstrategien DAMP und HAMP, verursacht werden. Dabei werden die SPM-

Großen 16kB und 256B betrachtet. Zwischen dem Energieverbrauch und der Laufzeit be-

Abbildung 6.19: Energie-Overhead bei ver-schiedenen Zeitscheibenlangen des MobileDevice Benchmarks, SPM-Große: 16kB

Abbildung 6.20: Energie-Overhead bei ver-schiedenen Zeitscheibenlangen des MobileDevice Benchmarks, SPM-Große: 256B

Abbildung 6.21: Laufzeit-Overhead bei ver-schiedenen Zeitscheibenlangen des MobileDevice Benchmarks, SPM-Große: 16kB

Abbildung 6.22: Laufzeit-Overhead bei ver-schiedenen Zeitscheibenlangen des MobileDevice Benchmarks, SPM-Große: 256B

steht auch in diesen Beispielen ein starker Zusammenhang. Die Energie- und Laufzeitwerte

liegen bei dem Mobile Device Benchmark uber denen des Industrial Benchmarks. Dies ist auf

82 6 Ergebnisse

die langere Laufzeit zuruckzufuhren. Dies hat auch Auswirkung auf den Overhead, da in den

Abbildungen nicht der Verbrauch pro Kontextwechsel dargestellt wird, sondern der Gesamt-

verbrauch. Die Energie- und Laufzeitbedarfe pro Kontextwechsel verhalten sich ahnlich wie

die Gesamtverbrauche. Auch hier kommt es zur Bildung von lokalen Minima, wie es in den

Abbildungen 6.19 und 6.21, bei der Zeitscheibenlange von 0,10ms, fur die SPM-Allokations-

Strategie DAMP der Fall ist. Der durchschnittliche Anteil des, durch die Kopiervorgange er-

zeugten Energieverbrauchs und der Laufzeit liegt bei dem Mobile Device Benchmark bei

2,5%. Das Maximum bei 6,5%.

Der Energiemehrverbrauch des Multiprozesssystem mit dem 256B großen SPM und Anwen-

dung der Allokations-Strategie DAMP, im Vergleich zu dem 16kB großen SPM und Anwen-

dung von DAMP, Abbildungen 6.19 und 6.20, wird durch den Prozess 0 (”md5“) verursacht.

Da ein 256B großer SPM einen geringeren Energieverbrauch aufweist als ein 16kB großer

SPM, konnen hier mehr Speicherobjekte profitabel ausgelagert werden. Dies verursacht einen

hoheren Overhead. Abbildungen 6.6 und 6.8 zeigen, dass dies einen geringen Energie- und

Laufzeitbedarf zur Folge hat. Der Mehrverbrauch der SPM-Allokations-Strategie HAMP, Ab-

bildungen 6.19 und 6.20, hat die gegenteilige Ursache. Hier besteht die Moglichkeit Speicher-

objekte in den statischen Teil des SPM auszulagern. Dadurch wird die Speicherkapazitat des

SPM immer ausgeschopft. Dies wirkt sich positiv auf den Energie- und Laufzeitbedarf aus.

Bei dem SPM der Große 256B werden weniger Speicherobjekte ausgelagert, als beim Ein-

satz des 16kB SPM. Dadurch resultieren die hohen Verbrauche von HAMP, welche in den

Abbildungen 6.6 und 6.8 visualisiert sind.


Energie- und Laufzeitbedarf der Kopiervorgangen des Telecommunication-DSP Benchmark,

werden in den Abbildungen 6.23 bis 6.26 dargestellt. Auch hier wurden die großten und kleins-

ten betrachteten SPM-Großen als reprasentative Beispiele ausgewahlt. Die fur die Bench-

Abbildung 6.23: Energie-Overhead beiverschiedenen Zeitscheibenlangen desTelecommunication-DSP Benchmarks, SPM-Große: 16kB

Abbildung 6.24: Energie-Overhead beiverschiedenen Zeitscheibenlangen desTelecommunication-DSP Benchmarks, SPM-Große: 256B

marks Industrial und Mobile Device gemachten Aussagen lassen sich auf diesen Benchmark

ubertragen. Die lokalen Minima fur DAMP sind fur den 256B-SPM besonders ausgepragt.

Dies ist darauf zuruckzufuhren, dass ab der Zeitscheibenlange 0,50ms sowohl fur den Pro-

6.3 Einfluss des Overheads auf die SPM-Allokations-Strategien DAMP und HAMP 83

Abbildung 6.25: Laufzeit-Overhead beiverschiedenen Zeitscheibenlangen desTelecommunication-DSP Benchmarks, SPM-Große: 16kB

Abbildung 6.26: Laufzeit-Overhead beiverschiedenen Zeitscheibenlangen desTelecommunication-DSP Benchmarks, SPM-Große: 256B

zess ”adpcm decode“, als auch fur den Prozess ”adpcm encode“ Speicherobjekte in den SPM

gewinnbringend in den SPM verschoben werden. HAMP weist fur die SPM-Große 256B, bei

einer Zeitscheibenlange von 0,50ms ein Minimum auf. Dieses ist aber sehr gering und wird in

den Abbildungen 6.24 und 6.26 nicht deutlich dargestellt. Der Anteil des Energie- und Lauf-

zeitbedarf der Kopierkosten am Gesamtbedarf fur den Telecommuntcation-DSP Benchmark,

liegt durchschnittlich bei 2,5% und maximal bei 4,5%.


Die starken Schwankungen in Bezug auf den Energie- und Laufzeitoverhead der SPM-Allo-

kations-Strategie DAMP konnen sich, uber alle Benchmarks und SPM-Großen gemittelt, wie

in den Abbildungen 6.27 und 6.28 dargestellt, nicht durchsetzen. Stattdessen ist ein klarer

Abwartstrend sowohl in Bezug auf den Energieverbrauch, als auch auf die Laufzeit, mit zu-

nehmender Zeitscheibenlange zu erkennen. Dies lasst sich durch die abnehmende Anzahl

Abbildung 6.27: DurchschnittlicherEnergieverbrauch-Overhead

Abbildung 6.28: Durchschnittlicher Laufzeit-Overhead

von Kontextwechsel bei langen Zeitscheiben erklaren. Da die lokalen Minima, wie beispiels-

weise in Abbildung 6.24 zu erkennen, insgesamt bei unterschiedlichen Zeitscheibenlangen

auftreten (abhangig von Benchmark und SPM-Allokations-Strategie), gleichen sie sich bei der

Berechnung der Durchschnittswerte aus. Insgesamt liegt der Overhead fur Laufzeit und Ener-

gieverbrauch, der durch HAMP verursacht wird, unter dem Overhead, welcher von DAMP

84 6 Ergebnisse

verursacht wird. HAMP profitiert hier von der Moglichkeit, den SPM in einen statischen und

einen dynamischen Part aufzuteilen. Hinzukommt, dass der Energie- und Laufzeitbedarf von

Systemen mit der Anwendung von HAMP insgesamt geringer ist, als der von Systemen, in

denen DAMP zur Anwendung kommt.

Abbildung 6.29 stellt den prozentualen Anteil des Energie- und Laufzeitbedarfs der Kopier-

vorgange uber alle Benchmarks, SPM-Großen und Allokations-Strategien gemittelt, dar. We-

gen der großen Korrelation von Laufzeit und Energieverbrauch, decken sich die prozentualen

Anteile. Im Allgemeinen haben kurze Zeitscheiben einen hoheren Anteil zur Folge. Dies er-

Abbildung 6.29: Durchschnittlicher Anteil des Energie- und Laufzeitbedarf am Gesamtbedarf

gibt sich durch das schlechte Verhaltnis von Zeitscheibenlange und Overhead. Es wirkt sich

wiederum die Tatsache, dass bei sehr kurzen Zeitscheibenlangen, im Durchschnitt, weniger

Speicherobjekte in den dynamischen Teil des SPM verschoben werden, positiv auf dieses

Verhaltnis aus, sodass der maximale Anteil die 4,5% Marke nicht uberschreitet.

Teilfazit (a):

Der durch die SPM-Allokations-Strategie HAMP verursachte Laufzeit- und Energieoverhead

ist im Allgemeinen geringer als der Laufzeit- und Energieoverhead, der von der SPM-Alloka-

tions-Strategie DAMP verursacht wird.

Teilfazit (b):

Der prozentuale Anteil am Gesamtenergie- und Gesamtlaufzeitbedarf, der durch die SPM-

Allokations-Strategien DAMP und HAMP hervorgerufenen Kopiervorgange, liegt, abhangig

von der Zeitscheibenlange, durchschnittlich zwischen 1% und 4,5%.

6.4 Verhalten Cache-basierter Systeme bei unterschiedlichen Zeit-

scheibenlangen


Die Abbildungen 6.30 und 6.31 stellen die Energieverbrauche und die Laufzeiten des In-

dustrial Benchmarks fur verschiedene Cachekonfigurationen bei unterschiedlichen Zeitschei-

benlangen dar. Die Energieverbrauche und Laufzeiten korrelieren nicht so stark, wie dies bei

6.4 Verhalten Cache-basierter Systeme bei unterschiedlichen Zeitscheibenlangen 85

Abbildung 6.30: Energiebedarf bei verschiedenen Zeitscheibenlangen des Industrial Benchmarks,Cache-Große: 16kB

Abbildung 6.31: Laufzeiten bei verschiedenen Zeitscheibenlangen des Industrial Benchmarks,Cache-Große: 16kB

den SPM-Allokations-Strategien der Fall ist. So weisen die UNI-Caches mit den Assoziati-

vitaten 4, 8 und 16 bei den Zeitscheibenlange ab 0,30ms starke Unterschiede bezuglich des

Energieverbrauchs auf, aber nur sehr geringe Unterschiede bezuglich der Laufzeit. Der Grund

dafur liegt in dem erhohten Verwaltungsaufwand bei hohen Assoziativitaten. Dieser wirkt sich

negativ auf die Energiebilanz aus, ohne, in diesem Beispiel, Vorteile bezuglich der Laufzeit zu

haben.

Insgesamt lasst sich ein Abwartstrend der Energie- und Laufzeitbedarfe in dem betrachte-

ten Zeitscheibenlangen-Intervall von 0,05ms bis 4,00ms erkennen. Dies gilt auch fur kleinere

Caches. Abbildungen 6.32 und 6.33 zeigen die Energie- und Laufzeitbedarfe fur Caches der

Abbildung 6.32: Energiebedarf bei ver-schiedenen Zeitscheibenlangen des IndustrialBenchmarks, Cache-Große: 256B

Abbildung 6.33: Laufzeiten bei verschiede-nen Zeitscheibenlangen des Industrial Bench-marks, Cache-Große: 256B

Große 256B. Bedingt durch die Große beschranken sich die Konfigurationen auf UNI-Caches

86 6 Ergebnisse

mit den Assoziativitaten 1 und 2 und dem 1-fach assoziativen SPLIT-Cache. Sehr pragnant ist

der Zuwachs an Energieverbrauch und Laufzeit im Verhaltnis zu 16kB großen Caches.

Die Cache-Misses liegen fur die Caches der Große 16kB zwischen 1% und 4%. Dabei weist

der UNI-Cache fur alle Zeitscheibenlangen, mit Cache-Misses zwischen 3% und 4%, die

schlechtesten Werte auf. Tendenziell sinkt der Wert der Cache-Misses mit wachsender Zeit-

scheibenlange. Es gibt jedoch Zeitscheibenlangen-Intervalle, in denen lokale Minima auftre-

ten. Die Tabelle 6.9 zeigt eine Gegenuberstellung der Caches-Misses, der Energieverbrauche

und der Laufzeiten in dem Intervall von 0,10ms bis 1,00ms fur den 1-fach assoziativen UNI-

Cache. Die Cache-Misses weisen bei der Zeitscheibenlange 0,30ms ein lokales Minimum auf.

Zeitscheibenlange[ms]

Cache-Misses[%]

Energiebedarf[µJ]

Laufzeit[ms]

0,10ms 3,74 711,10 40,630,20ms 3,54 635,59 31,440,30ms 3,46 610,96 28,760,50ms 3,48 596,59 26,651,00ms 3,34 576,94 24,97

Tabelle 6.9: Gegenuberstellung von Cache-Misses, Energiebedarf und Laufzeit fur UNI-Cache (A=1)

Die Unterschiede sind sehr gering und konnen sich auf die Energie- und Laufzeitwerte nicht

auswirken. Der Vorteil, dass bei dieser Zeitscheibenlange weniger Cache-Misses auftreten,

geht durch die erhohte Zahl an Kontextwechseln wieder verloren. Grundsatzlich kann die

These 4.1.1 aber nicht auf Caches ubertragen werden, wie Tabelle 6.10 deutlich macht. Hier

wird das Zeitscheibenlangen-Intervall zwischen 3,70ms und 4,00ms genauer betrachtet und

der Energieverbrauch des 1-fach assoziativen UNI-Caches und der SPM-Allokations-Strategie

DAMP verglichen. Beide weisen eine Speichergroße von 256B auf. Der Energieverbrauch der

Zeitscheibenlange[ms]

Cache-Energiebedarf[µJ]

DAMP-Energiebedarf[µJ]

3,70ms 1972,57 664,643,80ms 1967,38 664,263,90ms 1967,42 662,464,00ms 1967,37 662,46

Tabelle 6.10: Vergleich der Energiebedarfe von DAMP und UNI-Cache (A=1), Speichergroße: 256B

SPM-Allokations-Strategie DAMP weist auch fur die großen und eng zusammen liegenden

Zeitscheibenlangen das, der These 4.1.1 zugrunde gelegte, Verhalten auf. Fur den Cache

ist der Energiebedarf fur die Zeitscheibenlange 3,80ms geringer als der fur 3,90ms. Ab der

Zeitscheibenlange 3,70ms steigt der Bedarf wieder an. Dies lasst sich auch auf die Laufzei-

ten ubertragen. Es kann also bei Caches bezuglich des Energieverbrauchs und der Laufzeit

zu lokalen Minima kommen. Dennoch ist die Energieersparnis bei Verkurzung der Zeitschei-

benlange sehr gering. Abbildung 6.46 im Abschnitt 6.4.4 verdeutlicht, dass die Verbrauche bei

langen Zeitscheibenlangen tendenziell besser sind als bei Kurzen.


Die Tabellen 6.11 und 6.12 stellen die prozentualen Verbesserungen des Energieverbrauchs

und der Laufzeit fur die einzelnen Cachekonfigurationen zwischen der kleinsten betrachteten

Zeitscheibenlange von 0,05ms und der großten betrachteten Zeitscheibenlange von 4,00ms

dar. Fur den Industrial Benchmark ist der Einfluss der Zeitscheibenlange auf Caches mit viel

Allok.-Strategie proz. Verb.Energie / Laufz.

Cache UNI (A=1) 34% / 42%Cache UNI (A=2) 31% / 42%Cache UNI (A=4) 26% / 35%Cache UNI (A=8) 23% / 31%Cache UNI (A=16) 22% / 29%Cache SPLIT (A=1) 49% / 61%Cache SPLIT (A=2) 33% / 43%

Tabelle 6.11: Prozentuale Verbesserung derCaches, Cache-Große: 16kB (Industrial B.)


Cache UNI (A=1) 85% / 85%Cache UNI (A=2) 80% / 80%Cache SPLIT (A=1) 85% / 85%

Tabelle 6.12: Prozentuale Verbesserung derCaches, Cache-Große: 256B (Industrial B.)

Speicherkapazitat wesentlich geringer als auf Caches mit wenig Kapazitat. Die 256B großen

Caches weisen eine sehr schlechte Energie- und Laufzeiteffizienz auf. Da, im Gegensatz

zu den SPM-Allokations-Strategien DAMP und HAMP, das Aktualisieren des Pufferspeichers

beim Einsatz von Caches in die Zeitscheibe fallt, verkurzt dies die zur Verfugung stehende

Rechenzeit. Bei sehr kleinen Caches kommt es zu sehr vielen Cache-Misses. In diesem Fall

sind dies bis zu 25%. Das macht eine haufige Aktuallisierung des Caches erforderlich.

Der Vorteil, Speicherobjekte an verschiedenen Cache-Blocken einlagern zu konnen, wirkt sich

bezuglich des Einflusses der Zeitscheibenlange auf Energie und Laufzeiteffizienz positiv aus.


Abbildung 6.34: Energiebedarf bei verschiedenen Zeitscheibenlangen des Mobile Device Bench-marks, Cache-Große: 16kB

Die Energieverbrauche und Laufzeiten der verschiedenen Cachekonfigurationen fur den Mo-

bile Device Benchmark werden in den Abbildungen 6.34 bis 6.37 visualisiert. Insgesamt

liegen die Werte uber denen des Industrial Benchmarks. Dies ist wieder auf die langeren

88 6 Ergebnisse

Abbildung 6.35: Laufzeiten bei verschiedenen Zeitscheibenlangen des Mobile Device Benchmarks,Cache-Große: 16kB

Ausfuhrungszeiten der Prozesse zuruckzufuhren. Fur die, in den Abbildungen 6.34 bis 6.37

dargestellten Zeitscheibenlangen, kommt es fur den Mobile Device Benchmark zu keinem

lokalen Minimum. Das Verlangern der Zeitscheibenlange wirkt sich, auf jede Cachekonfigura-

tion, positiv, sowohl auf das Laufzeitverhalten, als auch auf den Energieverbrauch, fur die in

den Abbildungen dargestellten Zeitscheibenlangen, aus.

Fur den Mobile Device Benchmark konnen, wie in Tabelle 6.10 fur den Industrial Benchmark,

Abbildung 6.36: Energiebedarf bei verschie-denen Zeitscheibenlangen des Mobile DeviceBenchmarks, Cache-Große: 256B

Abbildung 6.37: Laufzeiten bei verschiede-nen Zeitscheibenlangen des Mobile DeviceBenchmarks, Cache-Große: 256B

ebenfalls sehr geringe Verbesserungen fur kurzere Zeitscheibenlangen, im Hinblick auf Ener-

gie und Laufzeit, beobachtet werden. Die maximale, beobachtete, lokale Verbesserung kann

0,05% nicht uberschreiten.

Die Cache-Misses fur die Caches der Große 16kB liegen zwischen 0,9% und 6,5%. Da-

bei weist wieder der 1-fach assoziative UNI-Cache fur alle Zeitscheibenlangen die meisten

Cache-Misses auf. Fur die 256B großen Caches liegen die Cache-Misses mit 16% bis 26%

wesentlich hoher. Auch fur den Mobile Device Benchmark kommt es, ahnlich wie in Tabel-

le 6.9 dargestellt, bei den Cache-Misses zu lokalen Minima. Diese wirken sich aber nicht so

stark auf den Energieverbrauch oder auf die Laufzeit aus, dass eine Verkurzung der Zeitschei-

benlange an dieser Stelle vorteilhaft ware.

Die Tabellen 6.13 und 6.14 listen die prozentualen Verbesserung der verschiedenen Cache-

konfigurationen in dem Zeitscheibenlangen-Intervall von 0,05ms bis 4,00ms auf. Wie fur den

Industrial Benchmark, gilt hier, dass Caches mit hoher Assoziativitat geringer von der Zeit-

scheibenlange beeinflusst werden, als Caches mit niedrigerer Assoziativitat. So weist der

16kB große direct-mapped Cache eine Verbesserung bezuglich der Laufzeit von 61% auf,




Tabelle 6.13: Prozentuale Verbesserung derCaches, Cache-Große: 16kB (Mobile DeviceBenchmark)



Tabelle 6.14: Prozentuale Verbesserung derCaches, Cache-Große: 256B (Mobile DeviceBenchmark)

wohingegen der 16-fach assoziative Cache eine Verbesserung von 30% aufweist.


Abbildung 6.38: Energiebedarf bei verschiedenen Zeitscheibenlangen des Telecom.-DSP Bench-marks, SPM-Große: 16kB

Abbildungen 6.38 bis 6.41 zeigen die verschiedenen Energieverbrauche und Laufzeiten bei

unterschiedlichen Zeitscheibenlangen des Telecommunication-DSP Benchmark fur Caches

der Große 16kb und 256B. Die Beobachtungen und Aussagen, die uber die Benchmarks

Industrial und Mobile Device getroffen wurden, konnen auf diesen Benchmark ubertragen

werden. Tendenziell sinken die Energieverbrauche und Laufzeiten mit steigender Zeitschei-

benlange. Dabei konnten auch fur den Telecommunication-DSP Benchmark lokale Verbesse-

rungen fur kurzere Zeitscheibenlangen beobachtet werden. Diese Verbesserungen betragen

maximal 0,1µJ und sind auf ein sehr enges Zeitscheibenlangen-Intervall beschrankt. Fur die,

in den Abbildungen 6.38 bis 6.41 dargestellten Zeitscheibenlangen, konnte keine Verbesse-

rung bezuglich der Energie- und Laufzeitbedarf beobachtet werden.

Fur die Cache-Misses ergeben sich fur diesen Benchmark bei der Zeitscheibenlange 0,05ms

im Vergleich zur Zeitscheibenlange 0,10ms, fur die Caches der Große 16kB, relativ starke

Verbesserungen. Diese liegen bei ca. 1 Prozentpunkt. Der Verlauf wird in Abbdilung 6.45 im

Unterkapitel 6.4.4 visualisiert. Bei der Zeitscheibenlange von 0,05ms ist die Anzahl der Kon-

90 6 Ergebnisse

Abbildung 6.39: Laufzeiten bei verschiedenen Zeitscheibenlangen des Telecom.-DSP Benchmarks,SPM-Große: 16kB

Abbildung 6.40: Energiebedarf bei verschie-denen Zeitscheibenlangen des Telecom.-DSPBenchmarks, SPM-Große: 256B

Abbildung 6.41: Laufzeiten bei verschiede-nen Zeitscheibenlangen des Telecom.-DSPBenchmarks, SPM-Große: 256B

textwechsel allerdings so hoch, dass sich dieser Vorteil nicht auf den Gesamtenergie- und

Gesamtlaufzeitbedarf auswirken kann.

Die prozentualen Verbesserungen, die sich fur das betrachtete Zeitscheibenintervall fur den

Telecommunikation-DSP Benchmark ergeben, werden in Tabelle 6.15 und 6.16 aufgelistet.

Auch fur diesen Benchmark hat die Veranderung der Zeitscheibenlange auf Caches mit einer

hohen Assoziativitat, grundsatzlich, einen geringeren Einfluss. Auffallig ist, dass fur diesen

Benchmark die Verbesserungen insgesamt starker ausfallen, als bei dem Industrial Bench-

mark und bei dem Mobile Device Benchmark. Dabei fallen die Verbesserungen des Mobi-



Tabelle 6.15: Prozentuale Verbesserung derCaches, Cache-Große: 16kB (Telcom.-DSPBenchmark) ´



Tabelle 6.16: Prozentuale Verbesserung derCaches, Cache-Große: 256B (Telcom.-DSPBenchmark)


le Device Benchmarks auch starker aus, als die des Industrial Benchmarks. Das lasst sich

ebenfalls fur die SPM-Allokations-Strategien beobachten. Der Grund liegt in der Anzahl der

Prozesse. Je hoher diese ist, desto mehr Kontextwechsel fallen besonders bei kurzen Zeit-

scheibenlangen an.


Die Abbildungen 6.42 und 6.43 zeigen den durchschnittlichen Energieverbrauch und die durch-

schnittlichen Laufzeiten der verschiedenen Caches. Dabei wird uber die Cachegroßen 2kB,

4kB, 8kB und 16kB gemittelt. Die Beschrankung auf diese Speicherkapazitaten ist notwendig,

da fur die Simulation eines 16-fach assoziativen Caches eine Mindestgroße von 2kB erforder-

lich ist.

Wie die Abbildungen 6.42 und 6.43 zeigen, sinkt im Durchschnitt der Energie- und Laufzeitbe-

darf bei wachsenden Zeitscheibenlangen. Die ausgepragten Minima, wie sie in Kapitel 4.1.1

Abbdilung 4.3 zeigt, konnten nicht nachgewiesen werden. Es konnen zwar lokale Verbes-

Abbildung 6.42: Durchschnittlicher Energie-bedarf der Caches bei verschiedenen Zeit-scheibenlangen

Abbildung 6.43: Durchschnittliche Laufzei-ten der Caches bei verschiedenen Zeitschei-benlangen

serungen bei verkurzter Zeitscheibenlange festgestellt werden, diese uberschreiten jedoch

die 0,05% Marke nicht und beschranken sich auf sehr kleine Zeitscheibenlangen-Intervalle.

Das zusatzliche Auftreten von Kontextwechseln bei kurzen Zeitscheiben wirkt sich wesent-

lich starker auf die Verbrauche aus, als die Ersparnis durch weniger Cache-Misses. Abbil-

Abbildung 6.44: Durchschnittswerte derCache-Misses

Abbildung 6.45: Cache-Misses des UNI-Caches (A.=4, 16kB) des Telecom.-DSPBenchmarks

92 6 Ergebnisse

dung 6.45 stellt exemplarisch die Cache-Misses bei verschiedenen Zeitscheibenlangen des

Telecommunication-DSP Benchmarks fur einen 4-fach assoziativen, 16kB großen, UNI-Cache

dar. Das Verlangern der Zeitscheibe wirkt sich hier, im Intervall von 0,05ms bis 0,20ms, ne-

gativ aus. Ein solches Verhalten kann fur verschiedene Zeitscheibenlangen-Intervalle fur fast

alle Cachekonfigurationen, aller Benchmarks, beobachtet werden. In Abbildung 6.44 sind die



Tabelle 6.17: Durchschnittliche, prozentuale Verbesserungen der verschiedenen Caches

durchschnittlichen Cache-Misses aller Cachekonfigurationen und aller Benchmarks, fur die

Großen 2kB bis 16kB dargestellt. In dieser Abbildung wird deutlich, dass lange Zeitscheiben

grundsatzlich weniger Cache-Misses zur Folge haben.

Die Tabelle 6.17 listet die durchschnittlichen Verbesserungen auf, die sich in dem betrachte-

ten Zeitscheibenlangen-Intervall fur die verschiedene Cachetypen ergeben. Wieder wurde die

Bildung der Mittelwerte auf die oben genannten Cachegroßen beschrankt. Der hohere Grad

der Beeinflussung des 2-fach assoziativen UNI-Cache im Vergleich zu dem 1-fach assoziati-

ven UNI-Cache, wie er in Tabelle 6.15 des Telecommunication-DSP Benchmarks beobachtet

werden kann, wird bei der Durchschnittsbildung uber die Cachegroßen 256B bis 16kB nicht

bestatigt. Es lasst sich festhalten, dass die Zeitscheibenlange weniger Einfluss auf Caches

hat, deren Assoziativitat hoch ist.

Das folgende Fazit, bezieht sich auf direct-mapped UNI-Caches der Große 256B. Diese wei-

sen die großte Beeinflussung durch die Zeitscheibenlange auf.

Teilfazit (a):

Eine Verlangerung der Zeitscheibenlange von 10% kann eine bis zu 86% kurzere Laufzeit und

einen bis zu 86% geringeren Energieverbrauch eines Multiprozesssystems mit Cache zur Fol-

ge haben.

Teilfazit (b):

Je hoher der Grad der Assoziativitat eines Caches ist, desto geringer ist der Einfluss der

Zeitscheibenlange.

6.5 Vergleich von Cache- und Scratchpad-basierten Systemen bei unterschiedlichenZeitscheibenlangen 93

6.5 Vergleich von Cache- und Scratchpad-basierten Systemen bei

unterschiedlichen Zeitscheibenlangen

Die Abbildungen 6.46 und 6.47 stellen den durchschnittlichen Energie- und Laufzeitbedarf

der SPM-Allokations-Strategie DAMP und den durchschnittlichen Energie- und Laufzeitbedarf

der Cachekonfigurationen aller Benchmarks gegenuber. Auch hier erfolgt die Beschrankung

auf die SPM- bzw. Cachegroßen 2kB, 4kB, 8kB und 16kB. Wie die Graphiken zeigen, weist

Abbildung 6.46: Durchschnittlicher Energie-verbrauch von DAMP und den Cachekonfigu-rationen

Abbildung 6.47: Durchschnittliche Laufzeitvon DAMP und den Cachekonfigurationen

Abbildung 6.48: Energiebedarf der SPM-Allokations-Strategien und verschiedener Caches desTelecom.-DSP Benchmarks (Speichergroße: 8kB)

die SPM-Allokations-Strategie DAMP, welche sehr hohe Verbrauche bei kleinen Zeitschei-

benlangen aufweist, uber alle betrachteten Zeitscheibenlangen einen geringeren Energiever-

brauch und kurzere Laufzeiten auf als Caches. Aus Grunden der Ubersichtlichkeit, werden

die Energie- und Laufzeitbedarfe der Strategien SAMP und HAMP nicht visualisiert. Wie Ab-

bildung 6.13 aber deutlich macht, ist SAMP fur die Zeitscheibenlangen 0,05ms bis 1,00ms

noch effizienter als DAMP. Ab 1,00ms ist der Energie- und Laufzeitbedarf von DAMP zwar

geringer als von SAMP, dennoch steigen die durchschnittlichen Verbrauche von SAMP nicht

uber die der durchschnittlichen Verbrauche der Caches. Die SPM-Allokation-Strategie HAMP

weist uber alle Zeitscheibenlangen einen besseren Energie- und Laufzeitbedarf auf als DAMP

und SAMP und somit auch als die unterschiedlichen Cachkonfigurationen. Dies gilt auch fur

94 6 Ergebnisse

die Speichergroßen 256B, 512B und 1kB.

Wie in Abbildung 6.48 zu sehen ist, gibt es Ausnahmen, in denen Caches einen geringeren

Energiebedarf aufweisen, als die SPM-Allokations-Strategie DAMP. Die Abbildung 6.48 stellt

die Energieverbrauche fur den Telecommunication-DSP Benchmark mit einer Speichergroße

von 8kB der SPM-Allokations-Strategien und der Cachekonfigurationen gegenuber. Fur die

Zeitscheibenlange 0,20ms ubersteigt der Energiebedarf von DAMP, den Energiebedarf des 2-

fach assoziativen SPLIT-Caches. Fur die Zeitscheibenlangen 0,05ms und 0,10ms weisen alle

Cachekonfigurationen einen geringeren Energiebedarf auf, als DAMP. Dass der Energiebedarf

der Allokations-Strategie DAMP hoher ist als der von Caches, beschrankt sich auf Speicher

mit hoher Speicherkapazitat, kurzen Zeitscheibenlangen und Caches mit hoher Assoziativitat.

Das Gleiche gilt fur Laufzeiten. SAMP und HAMP weisen weder in dem, in Abbildung 6.48 vi-

sualisierten Beispiel einen hoheren Energieverbrauch auf als Caches, noch in einem anderen

Testdurchlauf. Dies gilt auch fur die Laufzeit.

Tabellen 6.18 und 6.19 stellen die durchschnittlichen Verbesserungen der SPM-Allokations-

Strategien und der Cachekonfigurationen in dem Zeitscheibenlangen-Intervall von 0,05ms bis

4,00ms, mit Beschrankung auf die oben genannten Speichgroßen, gegenuber. SAMP und



Tabelle 6.18: Durchschnittliche, proz. Verbes-serungen der Cachekonfigurationen (Spei-chergroßen: 2kB, 4kB, 8kB, 16kB)


SAMP 54% / 59%DAMP 80% / 84%HAMP 63% / 68%

Tabelle 6.19: Durchschnittliche, proz. Ver-besserungen der SPM-Allokations-Strategien(Speichergroßen: 2kB, 4kB, 8kB, 16kB)

DAMP weisen fur die betrachteten Zeitscheibenlangen keine hohere Beinflussung auf als die

Cachekonfigurationen. Bei Beschrankung auf Speichergroßen bis 2kB, ist die Beeinflussung

der SPM-Allokations-Strategie DAMP die hochste. Tabellen 6.20 und 6.21 listen die Verbess-

serungen auf, die sich fur die 1-fach und 2-fach assoziativen UNI-Caches, den 1-fach assozia-



Tabelle 6.20: Durchschnittliche, proz. Verbes-serungen der Cachekonfigurationen


SAMP 59% / 61%DAMP 71% / 76%HAMP 62% / 64%

Tabelle 6.21: Durchschnittliche, proz. Verbes-serungen der SPM-Allokations-Strategien

6.6 Analyse der iterativen Optimierung im Arbeitsablauf 95

tiven SPLIT-Cache und den SPM-Allokations-Strategien ergeben. Hier konnen alle Speicher-

großen berucksichtigt werden. In diesem Vergleich weist auch DAMP einen geringeren Grad

der Beeinflussung durch die Zeitscheibenlange auf als die Cachekonfigurationen.

Teilfazit (a):

Die durchschnittlichen Energie- und Laufzeitbedarfe der SPM-Allokations-Strategien liegen

fur alle betrachteten Zeitscheibenlangen unter denen der Cachekonfigurationen.

Teilfazit (b):

Die Zeitscheibenlangen haben einen geringeren Einfluss auf Scratchpad-basierte Multipro-

zesssysteme als auf Cache-basierte Multiprozesssysteme.

6.6 Analyse der iterativen Optimierung im Arbeitsablauf

In dem, in Kapitel 5 vorgestellten Arbeitsablauf, wird mit Hilfe des Programms XAMPopt, Ab-

schnitt 5.1.7, eine iterative Optimierung durchgefuhrt. Diese ist notwendig, da die Anzahl der

Prozessaufrufe in die ILP-Gleichungen der SPM-Allokations-Strategien DAMP und HAMP ein-

gehen. Diese Anzahl wird durch die Profildatei zur Verfugung gestellt. Die Generierung dieser

Datei durch den outputGenerator, Abschnitt 5.1.2, erfolgt ohne SPM. Dadurch liegt die Zahl

der Aufrufe hoher, als in der Simulation mit SPM. Wie bereits in Abschnitt 5.1.7 beschrieben,

stellt XAMPopt die Ergebnisse der Simulation dem Arbeitsablauf zur Verfugung, wenn sich die

Anzahl der Aufrufe geandert hat.

Tabelle 6.22 stellt die Energieverbrauche der verschiedenen Iterationen des Industrial Bench-

marks fur die Allokations-Strategie DAMP bei einer Zeitscheibenlange von 0,95ms und einer

Speicherkapazitat von 16kB dar. Nach dem ersten Durchlauf wurde das Multiprozessystem

einen Energieverbrauch von 553,79µJ aufweisen. Die SPM-Belegung, welche diesen Ener-

Iteration Energieverbrauch [µJ]

1. 553,792. 380,523. 365,164. 365,16

Tabelle 6.22: Energieverbrauch bei verschiedenen Iterationsstufen des Arbeitsablaufes

gieverbrauch zur Folge hat, basiert auf der Anzahl der Prozessaufrufe aus der Simulation

ohne SPM. In der zweiten Iteration basiert die SPM-Belegung auf der Anzahl an Aufrufen

aus der Simulation mit SPM. Die Gesamtanzahl der Prozessaufrufe hat sich dabei von 108

auf 24 verringert. Die Veranderungen werden von Iteration zu Iteration geringer. In den fol-

genden Iterationen verringert sich die Gesamtzahl der Prozessaufrufe auf 19 und der Ener-

gieverbrauch auf 365,16µJ. Die beiden letzten Iterationen unterscheiden sich nicht mehr. Die

SPM-Belegung ist trotz verringerter Zahl an Prozessaufrufen unverandert.

96 6 Ergebnisse

Die maximale Anzahl an Iterationen lag bei den Benchmarks Industrial, Mobile Device und

Telecommunication-DSP bei 5. Tendenziell wachst die Anzahl der Speicherobjekte im SPM,

bei Anwendung von DAMP, von Iteration zu Iteration. Fur HAMP wachst der dynamische Part

des SPM. Dies lasst sich auf die geringeren Kopierkosten, durch weniger Prozessaufrufe,

zuruckfuhren.

Aufgrund der starken Korrelation von Energieverbrauch und Laufzeit bei Anwendung der

Allokations-Strategien, konnen die obigen Beobachtungen auch auf den Laufzeitbedarf uber-

tragen werden.

Teilfazit:

Die iterative Optimierung im Arbeitsablauf kann eine Verbesserung des Energie- und Laufzeit-

bedarfs der SPM-Allokations-Strategien DAMP und HAMP von bis zu 34% zur Folge haben.

6.7 Optimierung

In den folgenden Abschnitten wird die Zeitscheibenlangenoptimierung auf die Benchmarks

angewendet. Dabei dienen die, mit MPARM ermittelten Laufzeiten der einzelnen Prozesse,

als Grundlage. Die Optimierung wird also fur Average-Case-Laufzeiten durchgefuhrt. Im Ab-

schnitt 6.7.4 wird die Optimierung fur Worst-Case-Laufzeiten vorgestellt.

Exemplarisch wird fur jeden Prozess eine Deadline angegeben. Desweiteren wird die Laufzeit

fur den Kontextwechsel fur die folgenden Optimierungen auf 0,20ms gesetzt. Dieser Wert ent-

spricht einem, aufgrund der durchgefuhrten Tests, pessimistisch abgeschatzten durchschnitt-

lichen Overhead. Das vorgegeben Verhaltnis von Overhead zu Zeitscheibenlange und die

Soll-Antwortzeiten variieren zwischen den Benchmarks.

Die Optimierungen wurden zunachst mit dem Bergsteigeralgorithmus durchgefuhrt. Dieser lie-

fert, sofern moglich, die optimale Zeitscheibenlange. Alternativ wurde die Optimierung auch

mit dem Simulated Annealing- Algorithmus durchgefuhrt. Dieser liefert, mit der entsprechen-

den Konfiguration, ebenfalls optimale Zeitscheibenlangen. Dabei hat sich eine Starttempe-

ratur als sinnvoll herrausgestellt, die einem Zehntel der langsten Prozesslaufzeit entspricht.

Das ”Cooling-Schedule“ 5.5 stellte den besten Kompromiss zwischen Losungsgute und Lauf-

zeit des Simulated Annealing- Algorithmuses dar. ”Cooling-Schedule“ 5.3 hat auch sehr gute

Losungen zur Folge, ist aber in Bezug auf die Laufzeit des Algorithmuses unvorteilhaft. Bei

Anwendung des ”Cooling-Schedule“ 5.4 war die Losungsgute im Allgemeinen nicht sehr gut.


In Tabelle 6.23 sind in der mittleren Spalte die Laufzeiten der Prozesse aufgefuhrt. In der rech-

ten Spalte sind die einzuhaltenden Deadlines der Prozesse aufgelistet. Die Soll-Antwortzeit

wird hier mit 100,00ms vorgegeben und das Soll-Verhaltnis von Overhead und Zeitschei-

6.7 Optimierung 97

Prozess Laufzeit [ms] Deadline [ms]

Selectionsort (Proz. 1) 40,242 110,000StateChart (Proz. 2) 33,140 105,000Edgedetection (Proz. 3) 30,160 95,000

Tabelle 6.23: Laufzeiten und Deadlines der Industrial Benchmark Prozesse

benlange, auch als Quota bezeichnet, soll 10% nicht uberschreiten.

Das Ergebnis der Optimierung ist eine Zeitscheibenlange von 32,063ms, bei einem Quota von

0,62% und einer Antwortzeit von 64,728ms. Die Tabelle 6.24 vergleicht die durch die Opti-

mierung berechneten Terminierungszeitpunkte mit den simulierten Zeitpunkten. Dabei wurde

zum Einen ein Multiprozesssystem ohne SPM simuliert, ein solches ist Grundlage fur die Op-

timierung, und zum Anderen ein Multiprozesssystem mit SPM. Dabei kommt die, bezuglich

Laufzeit und Energiebedarf beste Allokations-Strategie zum Einsatz, HAMP. Die SPM-Große

betragt 16kB. Es wird also auf der einen Seite das bestmogliche Multiprozesssystem mit den

Optimierungswerten verglichen und auf der anderen Seite ein Multiporzesssystem mit der

unvorteilhaftesten Speicherhierachie. Bei der, unter Berucksichtigung der Deadlines, maxi-

Prozess BerechneterTerminie-rungszeitpunkt[ms]

SimulierterTerminie-rungszeitpunkt(k. SPM) [ms]

SimulierterTerminie-rungszeitpunkt(HAMP) [ms]

Deadline [ms]

Selectionsort(Proz. 1)

103,379 102,663 3,388 110,000

StateChart(Proz. 2)

104,776 103,811 13,0788 105,000

Edgedetection(Proz. 3)

95,000 94,534 15,8748 95,000

Tabelle 6.24: Ergebnisse der Optimierung des Industrial Benchmarks

mierten Zeitscheibenlange von 32,063ms halten alle Prozesses ihre Deadline ein. Dies gilt

nicht nur fur das Multiprozesssystem mit SPM, sondern auch fur das System ohne SPM. Da-

bei weichen die simulierten Werte des Systems ohne SPM nur ca. 1% von den berechneten

Werten ab. Der Puffer Xp der Prozesse steigt bei Einsatz der SPM-Allokations-Strategie stark

an.


In Tabelle 6.25 sind die Laufzeiten und Deadlines der Prozesse des Mobile Device Bench-

marks aufgefuhrt. Die Soll-Antwortzeit liegt bei 1s und der Soll-Quota bei 5%. Die hohe Dead-

line des Prozesses 1 leitet sich von dessen WCET ab.

Das Ergebniss der Optimierung ist eine Zeitscheibenlange von 5,921ms, bei einem Quota

von 3,27% und einer Antwortzeit von 18,563ms. Wie in Tabelle 6.26 ersichtlich wird, halten

98 6 Ergebnisse


md5 (Proz. 1) 210,030 4264,000jfdctint (Proz. 2) 0,574 9,000g723 encode (Proz. 3) 57,825 170,000g723 decode (Proz. 4) 46,591 150,000

Tabelle 6.25: Laufzeiten und Deadlines der Mobile Device Benchmark Prozesse

bei dieser Zeitscheibenlange alle Prozesse, sowohl fur das Multiprozesssystem mit, als auch

fur das Mulitprozesssystem ohne SPM, ihre Deadlines ein. Die maximale Abweichung der

simulierten und berechneten Terminierungspunkte liegt zwischen 1% und 4,5%. Auffallig ist,




Deadline [ms]

md5(Proz. 1)

326,020 317,288 103,408 4264,000

jfdctint(Proz. 2)

6,895 6,580 6,739 9,000

g723 encode(Proz. 3)

170,000 166,470 119,045 170,000

g723 decode(Proz. 4)

146,901 143,951 50,960 150,000

Tabelle 6.26: Ergebnisse der Optimierung des Mobile Device Benchmarks

dass der Terminierungszeitpunkt des Prozesses 2 mit SPM spater ist, als fur ein System ohne

SPM. Die Differenz betragt in etwa 0,16ms. Da fur den Prozess 2 keine Speicherobjekte in

den SPM verschoben werden, verandert sich dessen Laufzeit nicht. Die Differenz ergibt sich

aus dem, durch die SPM-Allokations-Strategie hervorgerufenen Overhead. Dieser Overhead

wird in dem Modell berucksichtigt. Der berechnete Terminierungszeitpunkt fur diesen Prozess

liegt somit auch uber der simulierten Laufzeit des Multiprozesssystems mit SPM.

Fur die kurze, optimale Zeitscheibenlange von 5,921ms ist der Prozess 3 verantwortlich. Erst

ab dieser Lange ist Prozess 1 so stark zergliedert, dass Prozess 3 seine Deadline einhalten

kann.


Die Laufzeiten und Deadlines der Prozesse des Telecommunication-DSP Benchmarks, wer-

den in Tabelle 6.27 aufgelistet. Der Soll-Quota fur dieses Beispiel liegt bei 5% und die Soll-

Antwortzeit bei 1s. Zu Beachten ist, dass die Ausfuhrungsreihenfolge der Prozesse nach ihren

Laufzeiten sortiert ist.

Die optimale Zeitscheibenlange liegt fur dieses Beispiel bei 27,734ms. Das Verhaltnis von

6.7 Optimierung 99


iir-filter (Proz. 1) 4,766 5,000Hamming Window (Proz. 2) 13,307 20,000fdct (Proz. 3) 24,083 50,000adpcm decode (Proz. 4) 26,402 70,000adpcm encode (Proz. 5) 27,734 100,000

Tabelle 6.27: Laufzeiten und Deadlines der Telecommunication-DSP Benchmark Prozesse

Overhead zu Zeitscheibenlange liegt bei 0,72%. Die Antwortzeit betragt 111,936ms. Alle simu-

lierten Terminierungszeitpunkte liegen unter den berechneten Zeitpunkten. Die Abweichung

der Zeitpunkte von den berechneten Werten fur das Multiprozesssystem ohne SPM liegt da-

bei zwischen 1% und 5%. Die optimale Zeitscheibenlange fur dieses Szenario wird durch die




Deadline [ms]

iir-filter(Proz. 1)

4,966 4,725 2,722 5,000

Hamming Win-dow (Proz. 2)

18,473 17,988 13,469 20,000

fdct(Proz. 3)

42,756 42,028 19,773 50,000

adpcm decode(Proz. 4)

69,358 68,387 32,010 70,000

adpcm encode(Proz. 5)

97,292 96,077 39,098 100,000

Tabelle 6.28: Ergebnisse der Optimierung des Telecommunication-DSP Benchmarks

Laufzeit des Prozesses 5 bestimmt. Diese Laufzeit bildet die obere Grenze des Suchinter-

valls. Aufgrund der Ausfuhrungsreihenfolge ist keine kurzere Zeitscheibe moglich. Wenn die

Zeitscheibenlange systematisch verkurzt wird, ist der Prozess 5 immer der erste, der einen

weiteren Aufruf benotigt. Dadurch kommt dieser nie in die Situation, von dem Zergliedern

eines vorgelagerten Prozesses zu profitieren.

6.7.4 WCET Optimierung

Prinzipiell ist mit diesem Optimierungsverfahren auch eine Worst-Case-Optimierung durch-

fuhrbar. Als Eingabe dienen in dem Fall nicht simulierte Laufzeiten, sondern die WCETs.

Diese konnen mit dem Tool aiT gewonnen werden. Exemplarisch wird dies im Folgenden fur

den Industrial Benchmark durchgefuhrt. Die Tabelle 6.29 stellt die WCETs und die Deadlines

gegenuber.

100 6 Ergebnisse


Selectionsort (Proz. 1) 233000 360000StateChart (Proz. 2) 45821 105000Edgedetection (Proz. 3) 72193 250000

Tabelle 6.29: Laufzeiten und Deadlines der Industrial Benchmark Prozesse

Das Ergebnis der Optimierung ist eine Zeitscheibenlange von 58,379ms. Die Antwortzeit be-

tragt 117,958ms bei einem Quota von 0,7%. Die Tabelle 6.30 listet die berechneten und simu-




Deadline [ms]

Selectionsort(Proz. 1)

353,814 40,195 3,387 360,000

StateChart(Proz. 2)

105,000 73,406 13,078 105,000

Edgedetection(Proz. 3)

236,772 103,631 15,874 250000

Tabelle 6.30: Ergebnisse der WCET-Optimierung des Industrial Benchmarks

lierten Terminierungszeitpunkte auf. Dabei wurde wieder ein Multiprozesssystem ohne SPM

und ein System mit 16kB großen SPM und Anwendung der Allokations-Strategie HAMP simu-

liert. Es wird im Vergleich zu den Optimierungen, bei denen die Laufzeiten der Prozesse im

voraus genauer bekannt sind, deutlich, dass die Werte starker differieren. Die Puffer Xp der

Prozesse sind sehr groß. In jedem Fall werden die Deadlines eingehalten.


Sowohl fur den Worst-Case als auch fur den Average-Case werden alle Deadlines eingehal-

ten. Die simulierten und berechneten Terminierungszeitpunkte weichen im Durchschnitt um

2,1% voneinander ab, wenn die Laufzeiten der einzelnen Prozesse im Vorfeld bekannt sind.

Die Zeitscheibenlange kann nur dann Einfluss auf die Terminierungsreihenfolge und somit auf

das Einhalten der Deadlines haben, wenn die Prozesse nicht nach ihren Laufzeiten sortiert

sind. Wie in Kapitel 4.2 bereits gezeigt wurde, ist die Sortierung bezuglich der Deadlines, wie

es bei dem EDD-Schedule der Fall ist, nutzlos, wenn eine bestimmte Antwortzeit eingehalten

werden soll.

Teilfazit:

Das, der Optimierung zu Grunde liegende Laufzeitmodell weist eine Abweichung von 1% bis

5%, zwischen den berechneten und simulierten Werten auf, wenn die Laufzeiten der Prozesse

im Vorfeld bekannt sind.

7 Zusammenfassung und Ausblick 101

Kapitel 7

Zusammenfassung und Ausblick

Die Ergebnisse in dem vorangegangenem Kapitel haben deutlich gemacht, wie stark der Ein-

fluss der Zeitscheibenlange in einem Multiprozesssystem mit Anwendung des RoundRobin-

Scheduling auf den Energie- und Laufzeitbedarf ist.

In SPM-basierten Systemen kann eine Verlangerung der Zeitscheibe um 10% eine bis zu

65% kurzere Laufzeit und einen bis zu 60% geringeren Energieverbrauch zur Folge haben.

Dabei ist, bedingt durch die Aktualisierung des SPM wahrend den Kontextwechseln, der Ein-

fluss auf die SPM-Allokations-Strategie DAMP am hochsten. Dennoch resultiert aus der An-

wendung dieser Strategie fur große Zeitscheibenlangen, ab 1,00ms, ein geringerer Energie-

und Laufzeitbedarf als durch die Anwendung von SAMP. SAMP hingegen ist fur sehr kurze

Zeitscheibenlangen, die ein haufiges Aktualisieren des SPM notwendig machen, die bessere

Wahl. Die aufwendige Bestimmung der SPM-Belegung bei Anwendung von HAMP, ist im Hin-

blick auf den Energie- und Laufzeitbedarf profitabel. HAMP weisst fur alle Zeitscheibenlangen

sehr geringe Verbrauche auf und ist der Regel die beste Wahl.

Wird in dem Multiprozesssystem als Pufferspeicher ein Cache verwendet, ist der Einfluss der

Zeitscheibenlange sogar um durchschnittlich 20%-Punkte hoher als der von SPM-basierten

Systemen. Dabei weisen Caches mit einer geringen Assoziativitat eine hohere Beeinflussung

auf, als Caches mit hoher Assoziativitat. Dies lasst sich auch fur den Energie- und Laufzeitbe-

darf beobachten. Hohe Assoziativitaten haben im Durchschnitt uber alle Zeitscheibenlangen

positiven Einfluss, sowohl auf die Laufzeit, als auch auf den Energieverbrauch.

Insgesamt liegen die Verbrauche von Cache-basierten Systemen uber denen von SPM-ba-

sierten Systemen. Einzige Ausnahme bildet die Allokations-Strategie DAMP, in Kombinati-

on mit sehr kurzen Zeitscheiben. Hier kann es vorkommen, dass Caches einen geringeren

Energie- und Laufzeitbedarf aufweisen.

Die These, dass eine Maximierung der Zeitscheibenlange, eine Minimierung des Laufzeit- und

Energiebedarfs zur Folge hat, konnte fur SPM-basierte Multiprozesssysteme bestatigt wer-

den. Fur Cache-basierte Systeme hingegen, existieren fur sehr kleine Zeitscheibenlangen-

Intervalle lokale Minima. Das bedeutet, dass, im Gegensatz zu SPM-basierten Systemen,

aus einer kurzeren Zeitscheibenlange ein geringerer Energie- und Laufzeitbedarf resultieren

102 7 Zusammenfassung und Ausblick

kann.

Das Laufzeitmodell hat sich als sehr zuverlassig erwiesen. Wenn die Laufzeiten der Prozesse

im Vorfeld bekannt sind, weichen die berechneten und simulierten Terminierungszeitpunk-

te der Prozesse nur um durchschnittlich 1% bis 5% voneinander ab. Eine Optimierung der

Zeitscheibenlange unter Berucksichtigung der Antwortzeit, Quota und Deadlines, welche auf

diesem Laufzeitmodell basiert, kann ein durchfuhrbares Schedule finden, sofern ein solches

existiert.

Insgesamt lasst sich festhalten, dass SPM-basierte Multiprozesssysteme mit einer moglichst

langen Zeitscheibenlange und der Allokations-Strategie HAMP den geringsten Energie- und

Laufzeitbedarf aufweisen. Auch fur andere preemptive Scheduling-Algorithmen sollte die An-

zahl der notwendigen SPM-Aktualisierungen bei der Wahl einer Allokations-Strategie beruck-

sichtigt werden.

Ausgehend von den implementierten SPM-Allokations-Strategien und den gewonnen Ergeb-

nissen, bietet sich die Analyse der folgenden Erweiterungen und Fragestellungen an:

Analyse der Durchfuhrbarkeit des RoundRobin-Schedules: Wie Abschnitt 6.7.3 des Er-

gebniskapitels bereits aufgezeigt hat, kann die Verkurzung der Zeitscheibenlange keinen Ein-

fluss auf die Terminierungsreihenfolge der Prozesse haben, wenn diese nach ihren Laufzei-

ten sortiert zur Ausfuhrung gebracht werden. Es ware zu prufen, ob weitere Kriterien ein

durchfuhrbares RoundRobin-Schedule, mit den gemachten Einschrankungen, verhindern.

Laufzeitmodell: Die Berechnung der Terminierungszeitpunkte mit Hilfe des Laufzeitmodells,

welches in Kapitel 4.3 vorgestellt wurde, weist eine relativ hohe WCET auf. Ein Laufzeitmo-

dell, das eine schnellere Berechnung erlaubt, kann die Optimierung der Zeitscheibenlange

beschleunigen, da es sowohl fur den Bergsteigeralgorithmus, als auch fur den Simulated

Annealing- Algorithmus grundlegend ist.

Automatisierte Quelltextannotation: Die Eingabe des profitAnnotators wird in Form einer

C-Datei bereit gestellt. Um eine Unterscheidung der verschiedenen Prozesse und den dazu-

gehorenden Speicherobjekten zu ermoglichen, mussen diese manuell im Quelltext gekenn-

zeichnet werden. Eine Erweiterung des profitAnnotators konnte diesen Arbeitsschritt automa-

tisieren.

Granularitat der Speicherobjekte: In der vorliegenden Arbeit konnen nur globale Variablen

und Funktionen in den SPM verschoben werden. Dabei ist es nicht moglich diese nur teil-

weise in den SPM zu verschieben um eine bessere Auslastung des Speichers zu erzielen. So

konnte, beispielsweise, in [VSM03] gezeigt werden, dass durch die Partitionierung von Arrays,

eine Energieeinsparung von 5,7% bis 17,6% erzielt werden kann.

ABBILDUNGSVERZEICHNIS 103

Abbildungsverzeichnis

1.1 RoundRobin-Scheduling. (a) Queue aller aktiven Prozesse. (b) Queue aller aktiven Prozesse nach-dem P2 sein Quantum aufgebraucht hat. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.1 Befehls-Pipeline des ARM7TDMI Prozessors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.2 In dieser Arbeit betrachtete Speicherhierarchien. (a) Speicherhierachie mit Cache und Hauptspei-cher. (b) Speicherhierachie mit Scratchpad und Hauptspeicher. . . . . . . . . . . . . . . . . . . . . 7

2.3 Aufbau von DRAM und seiner Speicherzellen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.4 Cache-Hauptspeicher-Struktur. (a) grundlegende Hauptspeicher-Struktur. (b) grundlegende Cache-Struktur. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.5 Aufbau einer SRAM-Speicherzelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.6 MPARM Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.7 SWARM Architektur mit SystemC-Wrapper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.8 RTEMS Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.9 Zustande der Tasks in RTEMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.10 Parameter eines Tasks in einer Echtzeitumgebung . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.11 Klassifizierung von Scheduling-Algorithmen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.1 Statische Allokation fur mehrere Prozesse (SAMP) . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.2 Dynamische Allokation fur mehrere Prozesse (DAMP) . . . . . . . . . . . . . . . . . . . . . . . . . 29

3.3 Hybride Allokation fur mehrere Prozesse (HAMP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

4.1 Beispiel fur den Einfluss der Zeitscheibenlange auf die Terminierungsreihenfolge. (a) Zeitschei-benlange von Q = 9 Zeiteinheiten. (b) Zeitscheibenlange von Q = 8 Zeiteinheiten. . . . . . . . . . . 37

4.2 Ausfuhrungsreihenfolge nach EDD-Schedule mit einer Zeitscheibenlange von Q = 9 Zeiteinheiten . 38

4.3 Erwartetes Verhalten bzgl. des Energiebedarfs von Cache-basierten Systemen bei unterschiedli-chen Zeitscheibenlangen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

4.4 Erwartetes Verhalten bzgl. der Laufzeit von Cache-basierten Systemen bei unterschiedlichen Zeit-scheibenlangen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

4.5 Erwartetes Verhalten bzgl. des Energiebedarfs von SPM-basierten Systemen bei unterschiedlichenZeitscheibenlangen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

104 ABBILDUNGSVERZEICHNIS

4.6 Erwartetes Verhalten bzgl. der Laufzeit von SPM-basierten Systemen bei unterschiedlichen Zeit-scheibenlangen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

4.7 Anzahl der verpassten Deadlines bei unterschiedlichen Zeitscheibenlangen . . . . . . . . . . . . . 43

4.8 Zusammenfassung der Einschrankungen fur die Optimierung der Zeitscheibenlange . . . . . . . . . 45

5.1 Darstellung des Arbeitsablaufs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

5.2 Adressen-Generierung fur SAMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

5.3 Adressen-Generierung fur DAMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

5.4 Adressen-Generierung fur HAMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

5.5 Beispiel fur die zusatzliche Dereferenzierungsstufe eines Multiprozesssystems mit zwei Prozessenund der SPM-Allokations-Strategie DAMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

5.6 Verwaltungsstruktur des SPMM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

5.7 Zeitpunkt der Konfiguration der Zeitscheibenlange (Standardmethode) . . . . . . . . . . . . . . . . 61

5.8 Zeitpunkt der Konfiguration der Zeitscheibenlange (Konfiguration des SWARM-Timers in sptask) . 62

5.9 Zeitpunkt der Konfiguration der Zeitscheibenlange (Konfiguration des SWARM-Timers mit spti-merset) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

5.10 Verlangerung der Zeitscheibe wegen atomarer Hauptspeicherzugriffe . . . . . . . . . . . . . . . . . 64

5.11 Arbeitsweise des Simulated Annealing- Algorithmus fur die Zeitscheibenoptimierung . . . . . . . . . 68

5.12 ”Cooling Schedule“: (a) Funktion 5.3 (b) Funktion 5.4 (c) Funktion 5.5 . . . . . . . . . . . . . . . . 69

6.1 Energiebedarf bei verschiedenen Zeitscheibenlangen des Industrial Benchmarks, SPM-Große: 16kB 73

6.2 Energiebedarf bei verschiedenen Zeitscheibenlangen des Industrial Benchmarks, SPM-Große: 256B 73

6.3 Laufzeitverhalten bei verschiedenen Zeitscheibenlangen des Industrial Benchmarks, SPM-Große:16kB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

6.4 Laufzeitverhalten bei verschiedenen Zeitscheibenlangen des Industrial Benchmarks, SPM-Große:256B . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

6.5 Energiebedarf bei verschiedenen Zeitscheibenlangen des Mobile-Device Benchmarks, SPM-Große:16kB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

6.6 Energiebedarf bei verschiedenen Zeitscheibenlangen des Mobile-Device Benchmarks, SPM-Große:256B . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

6.7 Laufzeitverhalten bei verschiedenen Zeitscheibenlangen des Mobile-Device Benchmarks, SPM-Große: 16kB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

6.8 Laufzeitverhalten bei verschiedenen Zeitscheibenlangen des Mobile-Device Benchmarks, SPM-Große: 256B . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

6.9 Energiebedarf bei verschiedenen Zeitscheibenlangen des Telecom.-DSP Benchmarks, SPM-Große:16kB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

6.10 Energiebedarf bei verschiedenen Zeitscheibenlangen des Telecom.-DSP Benchmarks, SPM-Große:256B . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

ABBILDUNGSVERZEICHNIS 105

6.11 Laufzeitverhalten bei verschiedenen Zeitscheibenlangen des Telecom.-DSP Benchmarks, SPM-Große: 16kB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

6.12 Laufzeitverhalten bei verschiedenen Zeitscheibenlangen des Telecom.-DSP Benchmarks, SPM-Große: 256B . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

6.13 Durchschnittlicher Energieverbrauch bei verschiedenen Zeitscheibenlangen . . . . . . . . . . . . . 78

6.14 Durchschnittliches Laufzeitverhalten bei verschiedenen Zeitscheibenlangen . . . . . . . . . . . . . 78

6.15 Energie-Overhead bei verschiedenen Zeitscheibenlangen des Industrial Benchmarks, SPM-Große:16kB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

6.16 Energie-Overhead bei verschiedenen Zeitscheibenlangen des Industrial Benchmarks, SPM-Große:256B . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

6.17 Laufzeit-Overhead bei verschiedenen Zeitscheibenlangen des Industrial Benchmarks, SPM-Große:16kB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

6.18 Laufzeit-Overhead bei verschiedenen Zeitscheibenlangen des Industrial Benchmarks, SPM-Große:256B . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

6.19 Energie-Overhead bei verschiedenen Zeitscheibenlangen des Mobile Device Benchmarks, SPM-Große: 16kB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

6.20 Energie-Overhead bei verschiedenen Zeitscheibenlangen des Mobile Device Benchmarks, SPM-Große: 256B . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

6.21 Laufzeit-Overhead bei verschiedenen Zeitscheibenlangen des Mobile Device Benchmarks, SPM-Große: 16kB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

6.22 Laufzeit-Overhead bei verschiedenen Zeitscheibenlangen des Mobile Device Benchmarks, SPM-Große: 256B . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

6.23 Energie-Overhead bei verschiedenen Zeitscheibenlangen des Telecommunication-DSP Benchmarks,SPM-Große: 16kB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

6.24 Energie-Overhead bei verschiedenen Zeitscheibenlangen des Telecommunication-DSP Benchmarks,SPM-Große: 256B . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

6.25 Laufzeit-Overhead bei verschiedenen Zeitscheibenlangen des Telecommunication-DSP Benchmarks,SPM-Große: 16kB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

6.26 Laufzeit-Overhead bei verschiedenen Zeitscheibenlangen des Telecommunication-DSP Benchmarks,SPM-Große: 256B . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

6.27 Durchschnittlicher Energieverbrauch-Overhead . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

6.28 Durchschnittlicher Laufzeit-Overhead . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

6.29 Durchschnittlicher Anteil des Energie- und Laufzeitbedarf am Gesamtbedarf . . . . . . . . . . . . . 84

6.30 Energiebedarf bei verschiedenen Zeitscheibenlangen des Industrial Benchmarks, Cache-Große:16kB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

6.31 Laufzeiten bei verschiedenen Zeitscheibenlangen des Industrial Benchmarks, Cache-Große: 16kB . 85

6.32 Energiebedarf bei verschiedenen Zeitscheibenlangen des Industrial Benchmarks, Cache-Große:256B . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

6.33 Laufzeiten bei verschiedenen Zeitscheibenlangen des Industrial Benchmarks, Cache-Große: 256B . 85

106 ABBILDUNGSVERZEICHNIS

6.34 Energiebedarf bei verschiedenen Zeitscheibenlangen des Mobile Device Benchmarks, Cache-Große:16kB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

6.35 Laufzeiten bei verschiedenen Zeitscheibenlangen des Mobile Device Benchmarks, Cache-Große:16kB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

6.36 Energiebedarf bei verschiedenen Zeitscheibenlangen des Mobile Device Benchmarks, Cache-Große:256B . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

6.37 Laufzeiten bei verschiedenen Zeitscheibenlangen des Mobile Device Benchmarks, Cache-Große:256B . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

6.38 Energiebedarf bei verschiedenen Zeitscheibenlangen des Telecom.-DSP Benchmarks, SPM-Große:16kB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

6.39 Laufzeiten bei verschiedenen Zeitscheibenlangen des Telecom.-DSP Benchmarks, SPM-Große: 16kB 90

6.40 Energiebedarf bei verschiedenen Zeitscheibenlangen des Telecom.-DSP Benchmarks, SPM-Große:256B . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

6.41 Laufzeiten bei verschiedenen Zeitscheibenlangen des Telecom.-DSP Benchmarks, SPM-Große:256B . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

6.42 Durchschnittlicher Energiebedarf der Caches bei verschiedenen Zeitscheibenlangen . . . . . . . . . 91

6.43 Durchschnittliche Laufzeiten der Caches bei verschiedenen Zeitscheibenlangen . . . . . . . . . . . 91

6.44 Durchschnittswerte der Cache-Misses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

6.45 Cache-Misses des UNI-Caches (A.=4, 16kB) des Telecom.-DSP Benchmarks . . . . . . . . . . . . 91

6.46 Durchschnittlicher Energieverbrauch von DAMP und den Cachekonfigurationen . . . . . . . . . . . 93

6.47 Durchschnittliche Laufzeit von DAMP und den Cachekonfigurationen . . . . . . . . . . . . . . . . . 93

6.48 Energiebedarf der SPM-Allokations-Strategien und verschiedener Caches des Telecom.-DSP Bench-marks (Speichergroße: 8kB) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

TABELLENVERZEICHNIS 107

Tabellenverzeichnis

6.1 Ubersicht der Benchmarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

6.2 Prozentuale Verbesserung der SPM-Allokations-Strategien, SPM-Große: 16kB (Industrial B.) . . . . 75

6.3 Prozentuale Verbesserung der SPM-Allokations-Strategien, SPM-Große: 256B (Industrial B.) . . . . 75

6.4 Prozentuale Verbesserung der SPM-Allokations-Strategien, SPM-Große: 16kB (Mobile Device B.) . 76

6.5 Prozentuale Verbesserung der SPM-Allokations-Strategien, SPM-Große: 256B (Mobile Device B.) . 76

6.6 Prozentuale Verbesserung der SPM-Allokations-Strategien, SPM-Große: 16kB (Telecom.-DSP B.) . 78

6.7 Prozentuale Verbesserung der SPM-Allokations-Strategien, SPM-Große: 256B (Telecom.-DSP B.) . 78

6.8 Durchschnittliche prozentuale Verbesserung der SPM-Allokations-Strategien . . . . . . . . . . . . . 79

6.9 Gegenuberstellung von Cache-Misses, Energiebedarf und Laufzeit fur UNI-Cache (A=1) . . . . . . 86

6.10 Vergleich der Energiebedarfe von DAMP und UNI-Cache (A=1), Speichergroße: 256B . . . . . . . . 86

6.11 Prozentuale Verbesserung der Caches, Cache-Große: 16kB (Industrial B.) . . . . . . . . . . . . . . 87

6.12 Prozentuale Verbesserung der Caches, Cache-Große: 256B (Industrial B.) . . . . . . . . . . . . . . 87

6.13 Prozentuale Verbesserung der Caches, Cache-Große: 16kB (Mobile Device Benchmark) . . . . . . 89

6.14 Prozentuale Verbesserung der Caches, Cache-Große: 256B (Mobile Device Benchmark) . . . . . . 89

6.15 Prozentuale Verbesserung der Caches, Cache-Große: 16kB (Telcom.-DSP Benchmark) . . . . . . . 90

6.16 Prozentuale Verbesserung der Caches, Cache-Große: 256B (Telcom.-DSP Benchmark) . . . . . . . 90

6.17 Durchschnittliche, prozentuale Verbesserungen der verschiedenen Caches . . . . . . . . . . . . . . 92

6.18 Durchschnittliche, proz. Verbesserungen der Cachekonfigurationen (Speichergroßen: 2kB, 4kB,8kB, 16kB) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

6.19 Durchschnittliche, proz. Verbesserungen der SPM-Allokations-Strategien (Speichergroßen: 2kB,4kB, 8kB, 16kB) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

6.20 Durchschnittliche, proz. Verbesserungen der Cachekonfigurationen . . . . . . . . . . . . . . . . . . 94

6.21 Durchschnittliche, proz. Verbesserungen der SPM-Allokations-Strategien . . . . . . . . . . . . . . . 94

6.22 Energieverbrauch bei verschiedenen Iterationsstufen des Arbeitsablaufes . . . . . . . . . . . . . . . 95

6.23 Laufzeiten und Deadlines der Industrial Benchmark Prozesse . . . . . . . . . . . . . . . . . . . . . 97

6.24 Ergebnisse der Optimierung des Industrial Benchmarks . . . . . . . . . . . . . . . . . . . . . . . . 97

108 TABELLENVERZEICHNIS

6.25 Laufzeiten und Deadlines der Mobile Device Benchmark Prozesse . . . . . . . . . . . . . . . . . . 98

6.26 Ergebnisse der Optimierung des Mobile Device Benchmarks . . . . . . . . . . . . . . . . . . . . . . 98

6.27 Laufzeiten und Deadlines der Telecommunication-DSP Benchmark Prozesse . . . . . . . . . . . . . 99

6.28 Ergebnisse der Optimierung des Telecommunication-DSP Benchmarks . . . . . . . . . . . . . . . . 99

6.29 Laufzeiten und Deadlines der Industrial Benchmark Prozesse . . . . . . . . . . . . . . . . . . . . . 100

6.30 Ergebnisse der WCET-Optimierung des Industrial Benchmarks . . . . . . . . . . . . . . . . . . . . 100

LITERATURVERZEICHNIS 109

Literaturverzeichnis

[ART04] ARM7TDMI, Technical Reference Manual. ARM Limited., r4p1 edition, 2004.

[BCZZ04] A. Bona, M. Caldari, V. Zaccaria, and R. Zafalon. High-level power characterization of the AMBA Bus

interconnect. Synopsys User Group, 2004.

[BSL+02] R. Banakar, S. Steinke, B. Lee, M. Balakrishnan, and P. Marwedel. Scratchpad memory: A design

alternative for cache on-chip memory in embedded systems. In In Tenth International Symposium on

Hardware/Software Codesign (CODES), Estes Park, pages 73–78. ACM, 2002.

[But02] G. Buttazzo. Hard Real-Time Computing Systems, Predictable Scheduling Algorithms and Applicati-

ons. Kluwer Academic Publishers - ISBN: 0-7923-9994-3, 2002.

[BZZ04] A. Bona, V. Zaccaria, and R. Zafalon. System level power modeling and simulation of high-end indus-

trial network-on-chip. In Proceedings of the conference on Design, automation and test in Europe.

IEEE Computer Society, 2004.

[CSB92] A. Chandrakasan, S. Sheng, and R. Brodersen. Low power cmos digital design. IEEE Journal of Solid

State Circuits, 27:473–484, 1992.

[CZG98] M. Chinosi, R. Zafalon, and C. Guardiani. Automatic characterization and modeling of power con-

sumption in static rams. In ISLPED ’98: Proceedings of the 1998 international symposium on Low

power electronics and design, pages 112–114, New York, NY, USA, 1998. ACM.

[Dal00] M. Dales. SWARM 0.44 Documentation. Department of Computing Science, University of Glasgow,

2000.

[FPT07] H. Falk, S. Plazar, and H. Theiling. Compile-time decided instruction cache locking using worst-case

execution paths. In CODES+ISSS ’07: Proceedings of the 5th IEEE/ACM international conference on

Hardware/software codesign and system synthesis, pages 143–148, New York, NY, USA, 2007. ACM.

[Hil04] U. Hilleringmann. Silizium-Halbleitertechnologie. Teubner Verlag - ISBN: 3-519-30149-0, 2004.

[HP03] J. Hennessy and D. Patterson:. Computer Architecture - a Quantitative Approach. Morgan Kaufmann

- ISBN: 978-1558-6072-48, 2003.

[ICD08] ICD-C Compiler framework. ICD - Informatik Centrum Dortmund e.V. , http://www.icd.de/es/icd-c/icd-

c.html, 2008.

[ILC08] ILOG Inc. ILOG CPLEX. http://www.ilog.com/products/cplex/, 2008.

[Jac55] J. Jackson. Scheduling a production line to minimize maximum tardiness. University of California,

1955.

[JNW08] B. Jacob, S. Ng, and D. Wang. Memory Systems - Cache, DRAM, Disk, pages 257–376. Morgan

Kaufmann Publishers - ISBN: 978-0-12-379751-3, 2008.

[KG02] A. Krishnaswamy and R. Gupta. Profile guided selection of arm and thumb instructions. SIGPLAN

Not., 37(7):56–64, 2002.

[LAB+04] M. Loghi, F. Angiolini, D. Bertozzi, L. Benini, and R. Zafalon. Analyzing on-chip communication in a

mpsoc environment. In DATE ’04: Proceedings of the conference on Design, automation and test in

Europe, pages 20–52, Washington, DC, USA, 2004. IEEE Computer Society.

110 LITERATURVERZEICHNIS

[LAK97] P. Laarhoven, E. Aarts, and J. Korst. Simulated annealing. In Local Search in Combinatorial Optimi-

zation, pages 91–120, 1997.

[LPB04] M. Loghi, M. Poncino, and L. Benini. Cycle-accurate power analysis for multiprocessor systems-

on-a-chip. In GLSVLSI ’04: Proceedings of the 14th ACM Great Lakes symposium on VLSI, pages

410–406, New York, NY, USA, 2004. ACM.

[Mac02] P. Machanick. Approaches to addressing the memory wall. Technical report, School of IT and Electri-

cal Engineering, University of Queensland, 2002.

[Mar06] P. Marwedel. Embedded System Design. Springer - ISBN: 978-0-387-29237-3, 2006.

[Mer03] D. Mery. Symbian OS Version 7.0, Functional description. Symbian Press, www.symbian.com, 2003.

[MWV+04] P. Marwedel, L. Wehmeyer, M. Verma, S. Steinke, and U. Helmig. Fast, predictable and low energy

memory references through architecture-aware compilation. Asia and South Pacific Design Automa-

tion Conference, 0:4–11, 2004.

[PFV+07] R. Pyka, C. Fassbach, M. Verma, H. Falk, and P. Marwedel. Operating system integrated energy

aware scratchpad allocation strategies for multiprocess applications. In SCOPES ’07: Proceedingsof

the 10th international workshop on Software & compilers for embedded systems, pages 41–50, New

York, NY, USA, 2007. ACM.

[REC03] RTEMS C User´s Guide, Edition 4.6.5. On-Line Applications Research Corporation, 2003.

[Rya95] M. Ryan. Market focus - insight into markets that are making the news in EE Times.

http://techweb.cmp.com/techweb/eet/embedded/embedded.html(Sept.11), 1995.

[Sal05] J. Sales. Symbian OS Internals, Real-time kernel programming . Symbian Press, www.symbian.com,

2005.

[Sch77] H. Schwefel. Numerische Optimierung von Computer-Modellen mittels der Evolutionsstrategie mit

einer vergleichenden Einfuhrung in die Hill-Climbing- und Zufallsstrategie. Birkhauser Verlag Basel -

ISBN: 3-7643-0876-1, 1977.

[Sea01] D. Seal. ARM architecture reference manual. Addison-Wesley - ISBN: 978-0201737196, 2001.

[Spi07] C. Spiegel. Global Electronics: High Growth Products and New Markets. In Research Report # GB-

IFT063A. http://www.electronics.ca/reports/technology/new markets.html, 2007.

[Sta00] W. Stallings. Computer Organization and Architecture: Design for Performance, 5th edition. Prentice

Hall - ISBN: 0-13-081294-3, 2000.

[Tak01] H. Takada. Real-time operating system for embedded systems. In Tutorial 2 - Software Development

Methods for Embedded Systems. Asia South-Pacific Design Automation Conference (ASP-DAC),

2001.

[Tan02] A. Tanenbaum. Moderne Betriebssysteme. Pearson Studium - ISBN: 3-8273-7019-1, 2., uberarb.

Aufl. edition, 2002.

[TeR07] Emerging Research Devices, 2007 Edition. International Technology Roadmap for Semiconductors,

http://www.itrs.net, 2007.

[VPW+05] M. Verma, K. Petzold, L. Wehmeyer, H. Falk, and P. Marwedel. Scratchpad sharing strategies for

multiprocess embedded systems: A first approach. IEEE 3rd Workshop on Embedded System for

Real-Time Multimedia (ESTIMedia), 2005.

[VR98] F. Vaandrager and G. Rozenberg. Lectures on embedded systems, LNCS, Vol. 1494. Springer -

ISBN: 978-3-540-65193-2, 1998.

[VSM03] M. Verma, S. Steinke, and P.r Marwedel. Data partitioning for maximal scratchpad usage. In ASPDAC:

Proceedings of the 2003 conference on Asia South Pacific design automation, pages 77–83, New

York, NY, USA, 2003. ACM.

[VT94] A. Wolfe V. Tiwari, S. Malik. Power analysis of embedded software: a first step towards softwarepower

minimization. Very Large Scale Integration (VLSI) Systems, IEEE Transactions on Volume 2, Issue

4,, 1994.

LITERATURVERZEICHNIS 111

[Weg99] I. Wegener. Theoretische Informatik - eine algorithmenorientierte Einfuhrung. B.G. Teubner Verlag -

ISBN: 3-519-12123-9, 1999.

[Wei91] M. Weiser. The Computer for the 21st Century. In Scientific American, Vol. 265 No. 3, pages 66–75,

1991.

[WiR07] Wind River General Purpose Platform, VxWorks Edition 3.6. Wind River Systems, Inc.,

www.windriver.com, 2007.

[WoC08] Worst-Case Execution Time Analyzer, aiT for ARM7. AbsInt Angewandte Informatik GmbH,

http://www.AbsInt.com, 2008.

Documents

Analyse des Einﬂusses der Zeitscheibenlange beim ...ls12- · PDF fileDiplomarbeit Analyse des Einﬂusses der Zeitscheibenlange beim¨ RoundRobin-Scheduling in Cache- und Scratchpad-basierten