TU BRAUNSCHWEIG
| Carl-Friedrich-Gauß-Fakultät | Informatik
Informatikzentrum

Visualization of Memory Access Patterns

BetreuerBjörn Cassens
ProfessorProf. Dr. Rüdiger Kapitza
IBR GruppeDS (Prof. Kapitza)
ArtBachelorarbeit
Statusabgeschlossen

Einleitung

In heutigen Servern ist der installierte RAM neben der CPU oder ggF. der Grafikkarte einer der größten Energiekonsument, der bis zu 40% des gesamt Energiebedarfs ausmachen kann. Daher ist auch die Betrachtung des RAM's für die Gestaltung energiegewahrer Systeme nötig. NVRAM zum Beispiel ist eine zukunftsträchtige Technologie, die neben einer höheren Speicherdichte auch den Energiebedarf des Hauptspeichers senken kann. Neben diesen positiven Eigenschaften von NVRAM weist diese Technologie auch negative Eigenschaften wie Beispielsweise höhere Schreiblatenzen oder ein höherer Energiebedarf für das Schreiben auf. Die heutigen Betriebssystemkerne gehen derzeit von symmetrischen Zugriffszeiten aus, da bisher nur DRAM als Hauptspeicher eingesetzt wird. In zukünftigen Systemen hingegen ist die parallele Nutzung von DRAM und NVRAM denkbar, die tiefgreifende Änderungen im Betriebssystemkern erfordern. Da bisher kein NVRAM wie Phase-Change RAM (PRAM) oder Spin-Transfer Torque RAM verfügbar ist, kann das Verhalten von NVRAM nur innerhalb einer Simulation nachgestellt werden. Um den Energiebedarf ermitteln zu können, müssen innerhalb der Simulation alle Schreib- und Lesezugriffe entsprechend gesammelt und ausgewertet werden. Dies erfordert eine feingranulare Simulation, die neben dem Speicher auch Caches und die CPU simulieren muss.

Problem

Dies führt zum Einem dazu, dass die Simulation von kleinen Programmen z.T. sehr lange dauern, weswegen eine Simulation auf einem Server wünschenswert ist. Neben der Rechenzeit ist auch die Anfallende Datenmenge im Berreich mehrerer GB und kann daher die Festplattenkapazität kleinerer Workstation-Rechner sprengen. Daher sollen die Daten auf dem Server gehostet werden und mittels einer Netzwerkverbindung zum Client (Workstation Rechner) bei Bedarf übertragen und dort visualisiert werden. Da es unmöglich ist, alle Daten zu überblicken, ist es zudem nötig eine Filterung der Daten vorzunehmen. Kriterien könnten sein, dass nur Speicherbereiche eines bestimmten Segments oder nur Speichersegmente mit einer mindest Anzahl von Schreibzugriffen angezeigt werden sollen. Vorzugsweise soll die Filterung ebenfalls auf einem Server statt finden um den Traffic im Netzwerk gering zu halten. Die Aufteilung soll daher in den Bereich Backend und Frontend erfolgen. Das Backend liest Daten vom Gem5 Framework ein und speichert diese persistent auf dem Server. Gleichzeitig sollen ankommende Verbindungen vom Backend verarbeitet werden, was neben dem Auslesen der Daten auch die vorherige Filterung und Übertragung der Daten enthält. Neben der Filterung sind auch Statistiken über die Daten zu erheben wie beispielsweise die mittlere Anzahl an Schreibzugriffen auf Speichersegmente. Das Frontend hingegen soll die GUI bereitstellen und Anfragen an den Server senden sowie die geschickten Daten empfangen können. Dabei sollen Filter parameter frei wählbar sein und deren Parametrisierung in der GUI vorgenommen werden können.

Aufgabenstellung

  • Einarbeitung in das Gem5 und NVMain Framework
  • Implementierung eines Backends (Server)
  • Implementierung diverser Filter im Backend
  • Implementierung diverser Statistiken im Backend
  • Implementierung eines Frontends (Client)
  • Implementierung der GUI im Frontend

Links


aktualisiert am 25.10.2016, 15:36 von Björn Cassens
printemailtop