Microprocessor Forum: Steiniger Weg zu Hunderten von Kernen

Auf dem Microprocessor Forum hat Intel gleich in zwei Vorträgen weitere Details aus dem hauseigenen Tera-Scale-Forschungsprogramm zur Entwicklung eines Prozessors mit Hunderten von Kernen gezeigt. Ravi Iyer, Principal Research Scientist, sprach über die Probleme der Cache- und Speicheranbindung. Je größer die Anzahl der Kerne wird, desto knapper wird insbesondere die Ressource Speicher beziehungsweise die Bandbreite zum Speicher. Außerdem müssen die Kerne sich immer mehr darüber abstimmen, wer gerade welche Daten im Cache hält.

Eine mögliche Lösung sieht Intel in einer hierarchischen Cache-Struktur. Dabei bekommt jeder Kern einen eigenen L1-Cache (16 bis 64 KByte). Den L2-Cache (256 KByte bis 1 MByte) teilt sich eine Hand voll Kerne, die zu einem Node gehören und der L3-Cache (8 bis 32 MByte) steht allen Nodes eines Prozessors (ein Sockel) zur Verfügung.

Intel trennt dabei die Daten von ihrer Verwaltung. Beim "Non-inclusive Cache Inclusive Directory" (NCID), können – müssen aber nicht – die Daten repliziert in den Caches vorliegen. Das für das Snoopfiltering benötigte Verzeichnis der Cachelines wird hingegen immer voll repliziert.

Als zusätzliche Ebene führt Intel riesige L4-Caches aus DRAM ein. Diese sitzen nicht mehr auf demselben Die, sondern werden entweder als multi chip package danebengeklebt oder kommen huckepack auf den Prozessor (stacked).

Dazu kommt noch eine Priorisierung (Quality of Service, QoS) der einzelnen Applikationen beziehungsweise virtuellen Maschinen beim Cache-Zugriff. So ist sichergestellt, dass nicht eine Applikation ständig den Cache der anderen invalidiert. Deutlich wird dies am Beispiel eines Webservers und einer Datenbank: Der Webserver empfängt ständig Daten, die er aber nur einmal braucht. Damit beansprucht er viel Cache, profitiert jedoch nicht davon. Die Datenbank hingegen fragt seltener nach Daten und wird daher ständig aus dem Cache verdrängt. Ihre Performance würde jedoch von viel Cache deutlich profitieren.

Welche Applikation wie viel Cache bekommt, wird dynamisch entschieden: Ein "Resource Monitor" wertet aus, ob die Applikation sich destruktiv auf den Cache auswirkt (Streaming data), davon profitiert (kooperative Threads), sich neutral verhält, weil sie wenig Daten nutzt, oder ganz normal ist. Anhand dieser Einschätzung und Voreinstellungen kann das Betriebssystem seine QoS-Einstellungen anpassen und das Resource Enforcement die Cache-Partitionen verschieben.

Zum Microprocessor Forum siehe auch:

• Auto fährt mit
• Dornröschenschlaf für Intel-CPUs
• Telematik-Chip von Freescale
• Massiv-Parallel-Prozessor für Bildanalyse

(bbe)