UltraSPARC III in Multiprozessoren Systemen und Organisation der Cache Kohärenz Domänen

Transkript

1 UltraSPARC III in Multiprozessoren Systemen und Organisation der Cache Kohärenz Domänen Bericht zum Vortrag am Fach: Labor Rechnerstrukturen des Fachbereiches Informatik an der Hochschule Bremen Autor: Ahmed Errabbah

2 Inhaltsverzeichnis 1 Einführung 4 2 System Konfigurationen Zwei-Prozessor Konfiguration mit UltraSPARC III L2 (Level2)-Cache Schnittstelle Boot Bus Schnittstelle JTAG Schnittstelle Vier-Prozessor Konfiguration mit UltraSPARC III Fireplane Interconnect DCDS (Dual CPU Data Switch) Schnittstelle Address Repeater SDRAM (Synchronous Dynamic Random Access Memory) Schnittstelle CPU/Memory Board PCI I/O Assemble Inter-Board Connect Multiprozessor System mit dem UltraSPARC III 11 3 Cache Kohärenz (Cache Coherency) Überblick über Cache Kohärenz in Multiprozessor Systemen mit einem single-bus Cache Kohärenz in Multiprozessor Systemen mit UltraSPARC III Cache-Kohärenz Arten Broadcast Kohärenz bzw. Snoopy Kohärenz Point to-point Kohärenz bzw. Directory Kohärenz Fireplane Kohärenz Protokoll Übersicht Fireplane Broadcast Kohärenz Address Bus Implementierung Snoop Signale Snoop Tags Cache Tags (CTags) Dual Tags (DTags) Fireplane Punkt-zu-Punkt Kohärenz (Point-to-Point Coherency) Fireplane Address Transaktionen Anfragen bezüglich lokaler Daten (Requests for local Data) Daten-Empfang für einen entfernten Anforderer (Get Data for a remote requester) Wiederausgabe entfernter Reads (Re-issue remote reads) I/O Transaktionen Fireplane Data Transfers Read Data Transfers Write Data Transfers 23 2

3 Daten-Pakete Beispiel für Fireplane Interconnect Operation Transfer innerhalb einer Snooping Coherence Domain (local Transfers) Übertragung zwischen Snooping Coherence Domains (Remote Transfers) Übertragungsarten - Zusammenfassung Cache-to-Cache Transfers In einer Snooping Coherence Domain Zwischen den Snooping Coherence Domains Eine single Snooping Coherence Domain Muliple Snooping Coherence Domains 30 4 Quellen 31 3

4 1 Einführung Den weltweit ersten RISC-Mikroprozessor, bei dem umfassende Multimedia-Funktionen für 2D/3D-Grafik, Bildbearbeitung und Video-Kompression/Dekompression direkt auf dem Chip integriert werden konnten, stellt SPARC Technology Business unter dem Namen UltraSPARC (Synchronous Processor Architecture) vor. Der UltraSPARC basiert auf der 64 Bit SPARC V9 Architektur und sorgt in komplexen, speicherintensiven Anwendungen für höchste Systemeffizienz und maximale Rechengeschwindigkeit. Aufgrund der strikten Binärkompatibilität zu den anderen SPARC-Mikroprozessoren kann der Anwender beim Einsatz des UltraSPARC auf eine Vielzahl von bewährten 32- Bit-Applikationen zurückgreifen. Das Ziel der Entwicklung war es, eine Einprozessorarchitektur zu entwickeln, die die Integration von so vielen Komponenten wie möglich (z.b. L1-Caches, Memory Controller, L2-Cache Controller etc) auf dem Prozessor-Chip erlaubt, um damit Systemkomponenten und Kosten zu reduzieren sowie allen Anforderungen der Kunden von Sun gerecht zu werden: Skalierbarkeit, höchstes Leistungsvermögen, optimierte Speicherverwaltung und herausragende Verlässlichkeit in allen Einsatzbereichen, von der Workstation über den Webserver bis hin zum Sun Fire 15K Server mit 106 Prozessoren. Die UltraSPARC III Prozessorfamilie ist mit allen anderen SPARC-basierten Prozessoren, die Sun seit 1987 ausgeliefert hat, binärkompatibel. Die Binärkompatibilität der verschiedenen Prozessorgenerationen gehört bei Sun von jeher zu den wichtigsten Prioritäten. So war das bereits 1994, als Sun die erste 64-Bit-Prozessorarchitektur einführte. Seither sind drei weitere Prozessorgenerationen (US I, US II, und US III) entwickelt worden, ohne dass deswegen eine einzige Zeile Quellcode neu kompiliert werden musste. Daher läßt die Architektur des UltraSPARC III auch ältere Applikationen auf neuen Systemen laufen. Der UltraSPARC III Cu Prozessor kann in einer Vielfalt von Konfigurationen von Zwei- Prozessor- Systemen bis zu sehr großen symmetrischen Multiprozessoren Systemen eingesetzt werden, wie z.b. in Sun Fire 3800 (mit 8 Prozessoren), Sun Fire 4800 (mit 12 Prozessoren), Sun Fire 6800 Cabinet (mit 24 Prozessoren) oder Sun Fire high-end Server (mit mehr als 24 Prozessoren) (siehe Punkt 3.13). Dieser Bericht versucht dem Leser einen Überblick über den Einsatz von UltraSPARC III in Multiprozessor Systemen sowie deren Cache-Kohärenz Organisation zu geben. 4

5 2 System Konfigurationen 2.1 Zwei-Prozessor Konfiguration mit UltraSPARC III Abb. 1 ist ein Beispiel für eine zwei-prozessor UltraSPARC III Cu Konfiguration. Diese Konfiguration ist der Basisaufbau, der benutzt wird, um SMP Systeme aufzubauen. In dieser Konfiguration sind beide UltraSPARC III Cu Prozessoren verbunden mit einem Dual CPU Daten-Verteiler (Data Switch) DCDS über eine 16-Byte Schnittstelle bei 150 MHz. Jeder Prozessor hat eine Adressen- und Kontroll-Schnittstelle zu den SDRAMs. Aber die Daten vom SDRAM sind direkt verbunden mit dem DCDS über eine 64-Byte Schnittstelle, die mit 75 Mhz läuft. Jede UltraSPARC III Cu CPU ist mit dem Fireplane Interconnect Address Bus verbunden. Die UltraSPARC III Cu CPU ist ebenfalls mit einem L2-Cache über eine 32-Byte Schnittstelle verbunden und mit dem Boot PROM (Boot Programmable Read-Only Memory ) über die Boot Bus Schnittstelle. Beide UltraSPARC III Cu CPUs haben eine JTAG (Joint Test Action Group ) Schnittstelle. Abb. 1: Zwei Prozessoren Konfiguration mit dem UltraSPARC III L2 (Level2)-Cache Schnittstelle Der UltraSPARC III Cu Prozessor steht in Verbindung mit einem bis zu 8 MB großen, 2-Wege Set assoziativen externen L2-Cache mit ECC (Error Checking and Correcting) Schutz über eine 32-Byte Schnittstelle, die mit 200 MHz oder höher läuft. 5

6 Die lokale Addressierung des L2-Caches und SDRAM geht über den Prozessor und die entfernte Addressierung geht über den Fireplan Address Interconnect und Prozessor (siehe Abb. 1). Alle Daten-Transfers vom und zum SDRAM erfolgen über den Dual CPU Data Switch (DCDS), deswegen können Daten zwischen SDRAM und L2-Cache nur über den DCDS ausgetauscht werden (mehr Details über den DCDS folgen) Boot Bus Schnittstelle Der UltraSPARC III Cu Prozessor hat eine Boot Bus Schnittstelle, die in Verbindung zu einem Boot PROM, anderen Booting- und diagnostischen Mechanismen steht JTAG Schnittstelle Der UltraSPARC III Cu Prozessor hat eine Standard JTAG (Joint Test Action Group) Schnittstelle. Diese Schnittstelle kann benutzt werden, um den internen Status der Fehler-Diagnose des Prozessors abzutasten (scan out). Ein vollständiger Scan ist eine Lösch-Operation (destructive operation), die es erforderlich macht, die CPU wieder starten zu lassen (durch einen Power-On-Reset (POR)), bevor sie nochmal benutzt werden kann. Zusätzlich bietet der UltraSPARC III Cu Prozessor auch eine Schatten (shadow) JTAG-Schnittstelle (Ergänzungsschnittstelle) an, die eine Untermenge (subset) des Status abzutasten erlaubt, während der Prozessor gerade arbeitet. 2.2 Vier-Prozessor Konfiguration mit UltraSPARC III Eine vier-prozessor Konfiguration ist aus einer zwei-prozessoren Konfiguration aufgebaut. Abb. 2 demonstriert auch, wie größere Systeme kreiert werden können, wenn man einen Adressen Wiederholer bzw. den sogenannten Address Repeater und einen Level 1 Daten-Verteiler (Data Switch) benutzt (mehr Details über diese Bauteile folgen noch). I/O Controller, Brücken Chips oder externe Geräte sind mit dem System über den Address Repeater und den Data Switch verbunden. Diese Konfiguration kann vervielfacht werden, um ein hochleistungsfähiges SMP-System (Symmetric Multiprocessor System) zu kreieren. Jede CPU ist mit einem L2-Cache und SDRAM Speicher verbunden und kann auf alle andere CPU s Speicher (L2-Caches und SDRAMs) über den Fireplane Interconnect zugreifen und Daten entfernt lesen oder schreiben. Wie die CPUs auf die einzelnen Speicher zugreifen und wie die Cache- Kohärenz organisiert ist, wird noch detailliert erklärt. 6

7 Abb. 2: Vier Prozessoren Konfiguration mit dem UltraSPARC III Fireplane Interconnect Der Fireplane Interconnect hat zwei Teile. Beide laufen charakteristischerweise in einem Bereich von bis zu 150 MHz:. Ein Bus für Adresse und Kontrolle (Fireplane Address Interconnect). Dieser Bus benutzt 37 Bits für die Adressierung plus Kontrolle (siehe Abb. 1 und 2), Arbitration und ECC (Error Checking and Correcting) Bits. Alle UltraSPARC III Cu Prozessoren sind direkt mit diesem Bus verbunden. Für die Errichtung größerer Multiprozessorsysteme wird ein Repeater Chip benutzt, um einen hierarchischen Bus zu kreieren. Hierarchisch, weil stufenweise alle vier Prozessoren sowie alle zwei I/O Controller über einen Address Repeater verbunden sind (siehe Abb. 2 und 3), und diese beiden Address Repeater über einen System Address Repeater verbunden sind. Diese Struktur wird je nach Größe der Prozessorkonfiguration vervielfacht.. Ein Punkt-zu-Punkt Daten Interconnect (Fireplane Data Interconnect). Dieser Bus hat 32 Bytes für Daten neben den ECC und die Routing Information. Sämtliche UltraSPARC III Cu Prozessoren sind mit dem Fireplane Interconnect Data Bus durch einen DCDS (Dual CPU Data Switch)-Verteiler verbunden. Um größere 7

8 Multiprozessorsysteme zu errichten, kann ein Punkt-zu-Punkt Daten-Netzwerk, das auf Level 1 Data Switch aufgebaut ist, benutzt werden (siehe Abb. 5 und 6 ) DCDS (Dual CPU Data Switch) Schnittstelle Der UltraSPARC III Cu Prozessor steht in Verbindung mit dem Dual CPU Daten- Verteiler (Dual CPU Data Switch) über eine 16-Byte Schnittstelle, die mit 150 MHz läuft und fähig ist, eine Spitzenbandbreite von 2.4 GB/s zu liefern. DCDS wird benutzt, um den Datentransfer zwischen den miteinander verbundenen CPUs und ihren nichtzugehörigen Speichern (z.b. eine CPU1 steht in Verbindung zu einer CPU2. Die CPU1 kann Daten vom oder zum Speicher der CPU2 nur über den DCDS übertragen und umgekehrt) sowie zwischen diesen CPUs und anderen Komponenten und Speichern zu ermöglichen (siehe Abb. 3 und 5). DCDS ist mit einem Fireplane Interconnect Board Data Switch verbunden, welcher mit 150 MHz läuft und eine Spitzenbandbreite von 4.8 GB/s liefern kann. Dieser ermöglicht den Datentransfer zwischen zwei DCDSs Address Repeater Address Repeater werden wie in Single-Prozessor-Systemen als Address Bus benutzt. Sie werden als Baumstruktur (siehe Abb. 3 und 5) aufgebaut und ermöglichen Addresstransfer zwischen den einzelnen System-Komponenten. Die Adressierung der einzelnen System-Komponenten geht also nur über die Address Repeater und der Datentransfer nur über die Data Switches SDRAM (Synchronous Dynamic Random Access Memory) Schnittstelle Der UltraSPARC III Cu Prozessor liefert Adressen und Kontrol-Bits zum SDRAM. Die Daten vom SDRAM werden direkt zum DCDS über eine 64-Byte Schnittstelle gesendet, die auf ein-halb der Fireplane Frequenz läuft. 8

9 Abb. 3: Vier Prozessoren Konfiguration und Snooping Kohärenz Domain mit dem UltraSPARC III CPU/Memory Board Das CPU/Memory Board Block Diagramm wird oben rechts im Abb. 3 gezeigt. Dieses Board wird von allen mid- und high-end Sun Fire servers benutzt. Der Board-level Address Repeater sammelt Adress-Anfragen (Requests) von den 4 Prozessoren auf dem Board und schickt diese zu einem Top-level Address Repeater auf den Switch- Boards (Verteiler-Boards). Er schickt auch Adressen zurück zu den Prozessoren, so dass sie diese gegen ihre Cache Inhalte snoopen (überprüfen) können. Eine CPU und ihre verbundene Speicher Einheit (Memory Unit) haben jeder einen 2.4 GBs Pfad zu einem Dual CPU Data Switch. Beide CPU/Memory Paare teilen sich einen 4,8 GBs Pfad zu dem Board Data Switch. Der Board Data Switch ist ein 3 x 3 Crossbarschalter, welcher die zwei Hälften des Boards mit dem off-board 4.8 GBs Fireplane Switch Port (System Data Switch) verbindet. Wenn alle Speicher-Zugriffe von jedem der vier CPUs zu jedem CPU eigenen lokalen Speicher ausgeführt würden, dann würde die Spitzen-Speicher-Bandbreite eines Boards 9.6 GBs (2.4 GBs * 4) betragen. 9

10 2.2.6 PCI I/O Assembler Die PCI Assembler für mittlere und größere Sun Fire Systeme haben alle die selbe Architekur, wie in Abb. 3 unten rechts und Abb. 4 gezeigt. Der Board-level Address Repeater sammelt Adress-Anfragen (Requests) von zwei PCI Controllern auf dem PCI Assembler und gibt sie weiter zu einem Top-level Address Repeater auf den Switch Boards. Jeder PCI Controller versorgt einen 33 MHz PCI Bus und einen 66 MHz PCI Bus. Die zwei PCI Controller sind mit dem Board Data Switch verbunden, der wiederum mit einem 2.4 GBs Fireplane Switch Port (System Data Switch) verbunden ist. Es gibt einige physikalisch unterschiedliche Implementierungen des PCI Assemblers, um sich an schmale und große Gehäuse (cabinets) sowie PCI und CompactPCI Form- Faktoren anzupassen. Alle PCI Assembler haben zwei 66 MHz und zwei bis sechs 33 MHz Steckplätze (slots). Abb. 4: PCI I/O Assembler Inter-Board Connect Die Logik des Interconnects zwischen den Boards einer Snooping Coherence Domain SCD (Details über SCD folgen in Punkt 3) wird auf der linken Seite in Abb. 3 gezeigt. Es gibt einen Top-level Address Repeater und einen Top-level Data Crossbarverteiler. Ein CPU/Memory Board hat einen 4.8 GBs (32-byte- breit bidirectional) Daten-Anschluß und ein I/O Assembler hat einen 2.4 GBs (16-byte-breit bidirectional) Anschluß. 10

11 2.3 Multiprozessor System mit dem UltraSPARC III Ein Multiprozessorsystem wie in Abb. 5 kann über die Benutzung mehrerer zweier-prozessoren Konfiguration errichtet werden. Ein Address- und ein Daten Repeater werden eingesetzt, um solche Systeme zu bauen. Verschiedene Geräte können mit dem System über die PCI Schnittstellen verbunden werden. Level 1 und Level 2 Address Repeater und Data Switches werden benutzt, um Systeme zu errichten, die auf bis zu sechs Prozessor/Memory Boards und bis zu vier I/O Untersysteme angepasst werden können. Abb. 5: Multiprozessorsystem mit dem UltraSPARC III (mit vier CPUs) Auf Level 0 befinden sich die einzelnen Komponenten (CPUs, SDRAMs und PCI Controller). Diese sind durch die Address Repeater auf Level 1 adressierbar und tauschen Daten mit den entfernten Komponenten nur über die Data Switches auf Level 1 aus. 11

12 Die Address Repeater auf Level 1 sind über einen System Address Repeater auf Level 2 miteinander verbunden (siehe Abb. 5). Dieser verwaltet die Adressen und schickt die Anfragen (Requests) zu der entsprechenden Komponente. Dasselbe gilt für die Data Switches; sie sind über einen System Data Switch (SDS) auf Level 2 verbunden und tauschen hierüber ihre Daten miteinander aus. Der SDS spielt dabei die Rolle eines Knotenpunktes für die Data Switches von Level 1. 3 Cache Kohärenz (Cache Coherency) Die Auswahl eines Cache-Kohärenz Schemas ist die wichtigste Design-Entscheidung für einen gemeinsamen Speicher Interconnect. Protokolle, die eine Cache-Kohärenz bei Multiprozessor-Systemen gewährleisten, heißen Cache-Kohärenz Protokolle (cache coherency protocols). Die Cache-Kohärenz Protokolle kontrollieren die Übereinstimmung (consistency) aller Caches. Kohärenz ist in Cache-Blocks gewährleistet, die typischerweise zwischen 32 und 128 Bytes groß sind. Momentan werden in den meisten Servern 64-Byte Cache-Blocks benutzt. Dieses Kapitel gibt dem Leser einen Überblick über Cache-Kohärenz Organisation in Multiprozessor-Systemen (MPS) mit einem Single Bus System und über die Cache Kohärenz bei MPS mit UltraSPARC III. Danach werden einige Grund-Begriffe erläutert (z.b. shared, modified, global shared, global modified...etc), um dem Leser die zwei danach folgenden Beispiele (local Data Transfers & Remote Data Transfer) verständlich zu machen. Zum Schluss werden diverse Workstations und Servers, die UltraSPARC III in ihren Multiprozessor Systemen benutzen, behandelt. 3.1 Überblick über Cache Kohärenz in Multiprozessor Systemen mit einem single-bus Die meisten populären Protokolle, die Cache-Kohärenz gewährleisten, werden Snooping genannt. In einem Single Bus Multiprozessor-System (siehe Abb. 6) überwachen oder snoopen alle Cache-Controller den Bus, um festzustellen, ob sie eine Kopie eines gemeinsamen (shared) Blocks haben oder nicht. Abb. 6 Single Bus Multiprozessor-System 12

13 Um Cache-Kohärenz zu gewährleisten, müssen zwei Operationen berücksichtigt werden, nämlich Read- und Write- Operationen. Mehrere Kopien von einem Cache-Block sind beim Lesen (Reading) kein Problem, aber um ein Wort dort hinein zu schreiben (Write), muss ein Prozessor exklusiven Zugriff darauf haben. Prozessoren müssen ebenfalls eine aktuelle Kopie besitzen, wenn sie Daten aus einem Block lesen; deshalb müssen alle Prozessoren nach einer Write-Operation ihre kopierten Daten mit den neuen Werten (values) aktualisieren oder annullieren. Snooping Protokolle müssen alle Caches lokalisieren, die ein gemeinsames Objekt für Write-Operationen besitzen. Die Status Bits (z.b. owned, shared etc.), die schon im Cache-Block sind, werden als Infos zu den Snooping Protokollen geschickt, und diese Informationen werden bei der Überwachung der Bus-Aktivitäten benutzt. Bei einer Read-Miss von einem Prozessor in einen bestimmten Cache, prüfen alle anderen Caches, ob sie eine Kopie des angefragten Blocks haben und führen dann die geeignete Aktion aus, wie z.b. die fehlenden Daten dem betroffenden Cache zu schicken. Bei einer Write-Operation prüfen alle Caches in ähnlicher Weise, ob sie eine Kopie haben und führen dann eine Aktion aus, indem sie entweder die Kopie ungültig machen (invalidate) oder mit dem neuen Wert updaten. Es gibt zwei Arten von Snooping Protokollen, die davon abhängen, was bei einer Write- Operation passiert: - Write-Invalidate: Der schreibende Prozessor macht alle Kopien in anderen Caches ungültig, bevor er seine lokale Kopie ändert; er kann dann die lokalen Daten updaten, bevor ein anderer Prozessor sie anfordert. Der schreibende Prozessor sendet ein Üngültigmachen-Signal über den Bus und alle Caches prüfen, ob sie eine Kopie besitzen. Wenn ja, müssen sie den Block, der das Wort beinhaltet, ungültig machen. Folglich läßt dieses Schema mehrere Leser aber nur einen Schreiber zu. - Write-Update: Anstatt jeden gemeinsamen Block ungültig zu machen, sendet der schreibende Prozessor die neuen Daten über den Bus nach einer Write-Operation: Alle Kopien werden dadurch mit dem neuen Wert upgedatet. Dieses Schema, auch Write-Broadcast genannt, sendet (broadcasts) kontinuierlich Writes zu gemeinsamen Daten, während Write-Invalidate alle anderen Kopien löscht, so dass nur eine lokale Kopie für spätere Writes vorhanden ist. Write-Update ist ähnlich wie Write-Through, weil alle Writes über den Bus gehen, um Kopien von gemeinsamen Daten (shared data) upzudaten. Write-Invalidate benutzt den Bus nur beim ersten Write, um die anderen Kopien ungültig zu machen. Deshalb lösen spätere Writes (vom selben Prozessor in den selben Cache-Block) keine Bus Aktivitäten aus. Folglich hat Write-Invalidate ähnliche Vorteile wie Write-Back was die Reduzierung der Anforderung an die Bus Bandbreite betrifft, während Write-Update den Vorteil hat, dass sie neue Werte schneller im Cache erscheinen läßt, was eine Reduzierung der Latenzzeit ermöglicht (mehr Details darüber siehe Computer Organisation & Design von D.A. Patterson and J.L. Hennessy). 13

14 Was passiert, wenn zwei Prozessoren im gleichen Taktzyklus auf den selben geteilten Speicherblock schreiben wollen?! 1. Einem der beiden Prozessoren wird zuerst der Bus zugeteilt. 2. Der erste Prozessor schreibt seine Daten. 3. Dem zweiten Prozessor wird der Bus zugeteilt. 4. Der zweite Prozessor schreibt seine Daten. Durch den Bus wird also ein sequentielles Verhalten beim Schreiben erzwungen. Nur so ist es möglich, dass das Schreiben mehrerer Prozessoren in den selben Speicherblock korrekt funktioniert. Beispiel für ein Cache-Kohärenz Protokoll Jeder Cache-Block ist in einem von drei verschiedenen Zuständen : 1. Read Only : Dieser Cache-Block ist nicht beschrieben (clean) und kann mitbenutzt werden. 2. Read / Write : Dieser Cache-Block ist beschrieben (dirty) und kann nicht mitbenutzt werden. 3. Invalid : Dieser Cache-Block enthält keine gültigen Daten. a) Cache-Status Veränderungen durch den zugehörigen Prozessor : Beispiel für ein Cache-Kohärenz Protokoll (Fortsetzung) Wann kommt es zu Cache -Status-Veränderungen? 14

15 Der Cache-Status wird verändert, wenn ein Leseversuch nicht funktioniert (read miss). Der Cache-Status wird verändert, wenn ein Schreibversuch nicht funktioniert (write miss). Der Cache-Status wird verändert, wenn ein Schreibversuch funktioniert (write hit). Was passiert bei einem read miss? 1. Der Status des Cache-Blocks wird auf Read Only gesetzt. 2. Wenn der alte Cache-Block auf Read / Write gesetzt war, so schreibt der Cache den alten Block in den Speicher. 3. Alle Caches der anderen Prozessoren überprüfen, ob sie eine Kopie des betroffenen Cache-Blocks haben, der auf Read / Write gesetzt ist. Ist dies der Fall, so setzen sie ihn auf Invalid (oder Read only). Was passiert, wenn der Prozessor auf einen Cache-Block schreiben will? 1. Der Prozessor sendet ein Invalidate-Signal über den Bus. Die Caches der anderen Prozessoren überprüfen, ob sie eine Kopie des Blocks haben und setzen diese, falls vorhanden, auf Invalid. 2. Der schreibende Prozessor schreibt in seinen Cache-Block und setzt ihn auf Read / Write. 3.2 Cache Kohärenz in Multiprozessor Systemen mit UltraSPARC III Jeder Prozessor kann der Besitzer (owner) jedes Cache-Blocks für bestimmte Zeit werden, indem er ihn mit dem Status valid in seinem Cache führt (Details folgen). Cache Verfehlungen (Misses) werden normalerweise vom ursprünglichen Speicher der Daten abgerufen, es sei denn eine Systemkomponente (ein anderer Prozessor oder I/O Controller) hat den betroffenen Cache-Block geändert. In diesem Fall haben die betroffenen Daten im Speicher einen invalid Status. Um eine Write Operation zu machen, muss der Prozessor der Besitzer (owner) des Cache-Blocks werden. Alle anderen Systemkomponenten annulieren (invalidate), jede geteilte (shared) Kopie von diesem Block, den sie in ihren Caches haben und der aktuelle Besitzer liefert ihnen die neuen Daten nach der Änderung. Wenn andere Prozessoren eine Read-only Kopie der Daten anfordern (request), dann liefert sie der Prozessor, der diese Daten besitzt und nicht der Speicher. Dieser wird jedoch wieder zum Besitzer, wenn der besitzende Prozessor in seinem Cache für neue Daten Platz frei machen muß, und er löscht den Cache-Block, nachdem er ein Write-back zum Speicher vorgenommen hat. 15

16 UltraSPARC III Cu -basierte Systeme unterstützen ein Snooping -basiertes Cache- Kohärenz Protokoll und ein Verzeichnis-(directory) basiertes Cache Protokoll (siehe Punkt und Punkt ). Für kleine bis mittelgroße Systeme verwendet der UltraSPARC III Cu Prozessor ein MOESI (Modified, Owned, Exclusive, Shared, Invalid) Snooping Protokoll. Wenn der Prozessor einen Cache-Block haben will, übersendet er in diesem Protokoll eine Anforderung (Request) zu allen anderen Prozessoren, die daraufhin ihre Caches durchsuchen, um zu prüfen, ob sie diesen Block haben oder nicht (Details folgen später). Für größere Systeme hat der UltraSPARC III Cu Prozessor eine eingebaute Unterstützung für ein Verzeichnis-basiertes Kohärenz Protokoll Cache-Kohärenz Arten Es gibt prinzipiell zwei Arten von Cache-Kohärenz: Broadcast und Point-to-Point Broadcast Kohärenz bzw. Snoopy Kohärenz Alle Adressen werden an alle Systemkomponenten gesendet. Jede Komponente überprüft ( snoops ) den Status vom angeforderten Cache-Block in ihrem lokalen Cache, und das System bestimmt ein globales Prüfergebnis (Snoop Result) ein paar Zyklen später. Broadcast Kohärenz bietet die niedrigste mögliche Latenzzeit, besonders für Cache-to- Cache Übertragungen, die in Transaktions-Prozessen üblich sind. Die Daten-Bandbreite von einem Snoop System ist wie folgt durch die Snoop-Bandbreite beschränkt: Bandbreite = Cache Block-Breite * Bus Clock / Clocks pro Snoop Point to-point Kohärenz bzw. Directory Kohärenz In Directory-basierten Protokollen gibt es ein einzelnes Verzeichnis, das alle Stati der Cache-Blocks (z.b. owned, shared...etc.) in einem Hauptspeicher bzw. speziellem RAM registriert. Dieses Verzeichnis beinhaltet auch Informationen darüber, welche Caches Kopien von welchen Blocks besitzen und welche Stati diese Blocks in den andern Caches haben (z.b. valid, invalid, dirty oder modified). Nach einem Update von einem Block durch eine Systemkomponente wird die Block- Adresse nur zu den Systemkomponenten geschickt, die sich für diesen Cache-Block interessieren bzw. die eine Kopie davon lokal bei sich haben, um sie (die Kopie) zu annulieren oder zu updaten (mehr Details darüber folgen). Weil nicht jede Adresse überall hin gesendet wird, kann die totale Bandbreite höher als bei Broadcast Kohärenz sein; dafür ist aber die Latenzzeit länger. Verzeichnis Kohärenz wird normalerweise nur in großen Systemen benutzt, in denen eine größere Bandbreite gebraucht wird als das Broadcast Kohärenz anbieten kann. 16

17 Abb. 7: Broadcast und Point-to-Point Cache Kohärenz. 3.3 Fireplane Kohärenz Protokoll Übersicht Das Sun Fireplane Protokoll wird von allen Systemen, die mit einem UltraSPARC III Prozessor arbeiten, benutzt. Der Fireplane Interconnect ist eine Verbesserung der vorherigen Generation der Ultra Port Architektur (UPA). Die jetzige Fireplane Architektur hat eine separate Adresse und Daten Interconnect, um Adress- und Daten Transfer Geschwindichkeit zu erhöhen. Der Adressen Interconnect verbreitet Lesen- und Schreiben-Anforderungen (Read- and Write-Requests) und behält die Cache Kohärenz bei. Der Daten Interconnect überträgt 64-Byte Blocks von der Quelle zum Zielpunkt. Das Fireplane Interconnect Protokoll besitzt als neue Haupteigenschaft ein zwei-level Cache Kohärenz Protokoll: 1. Broadcast (bzw. Snoopy). 2. Point-to-Point (bzw. Directory). (siehe Abb. 8) Abb. 8: Zwei-level Kohärenz Protokoll 17

18 Der UltraSPARC-III Prozessor Chip und I/O Controller ASICS ist logisch aufgebaut, um beide Level des Fireplane Kohärenz Protokolls zu leiten (manage). Sun kann eine große Bandbreite von System-Größen vom selben CPU/Memory Board und selben I/O Controller ASIC aufbauen, indem es (SUN) beide Typen der Kohärenz benutzt:. Mittelgroße Fireplane Systeme benutzen eine einfache Snooping Coherence Domain, welche alle Geräte umfasst, die mit einem Fireplane Address Bus verbunden sind. Snoopy Kohärenz gibt den Multiprozessorservern (mit 24 Processoren) in mittelgroßen Systemen eine ziemlich niedrige Memory Latenzzeit (latency).. Große Fireplane Systeme (mit > 24 Prozessoren) verwenden multiple Snooping Coherence Domainen. Dieses Protokoll (Fireplane Kohärenz Protokoll) nennt man Scalable Shared Memory (SSM) (skalierbarer geteilter Speicher). Große Systeme behalten die geringe Latenzzeit der Snoopy Kohärenz für den lokalen Speicher Zugriff zurück. Diese Ausführung beschreibt, wie SSM in einem großen single-cabinet System (Ein- Gehäuse-System) benutzt wird, wo die SSM Transaktionen mittels großer Pfade durch ein aktives Centerplane implementiert wird. Das SSM Protokoll kann auch mit anderen Interconnect Implementationen verwendet werden. 3.4 Fireplane Broadcast Kohärenz Alle Fireplane Systeme haben mindestens eine Snooping Coherence Domain. Innerhalb einer solchen Snooping Coherence Domain können Transaktionen von allen Geräten aufgespürt ( snoop ) werden. Snoop Ergebnisse sind der Output von allen Geräten 5 Zyklen, nachdem sie eine Adresse erhalten haben. Das Gesamt Snoop Ergebnis ist verknüpft durch ASICs/Chips auf jedem Board und wird zurückgesendet zu den Geräten 4 Zyklen später. 3.5 Address Bus Implementierung Der Address Bus ist dadurch implementiert, dass er eine zwei-level bidirektionale Baum-Struktur des Address Repeaters ASICs benutzt, wie in Abb. 9 ersichtlich ist. 18

19 Abb. 9: Address Bus Implementierung Die CPU 0 gibt eine ausgehenden Anfrage heraus (angezeigt durch einen einfachen roten Pfeil) im Takt (cycle) 0 zu seinem Board Address Repeater (AR0). Vorausgesetzt, dass der Bus zu dem Top-Level Address Repeater verfügbar ist, wird die herausgehende Anfrage (request) in Takt 2 gesendet. In Takt 3 entscheidet der Top-Level Address Repeater zwischen den zu ihm kommenden Anfragen und wählt eine Anfrage aus, um sie zurück zu den Board-Level Address Repeatern (AR0, AR1, AR2,...) zu senden. In diesem Beispiel wird die Anfrage physikalisch nur zu AR1 übertragen (angezeigt durch einen gestrichelten grünen Pfeil). Da AR0 die originale Anfrage gesendet hat und eine Kopie davon behält, wird er nur benachrichtigt, wenn die Kopie gebraucht wird. Folglich ist in Takt 4 der AR0 bis AR2 Bus physikalisch nicht benutzt (angezeigt durch den gepunkteten grünen Pfeil). In Takt 6 haben alle System-Geräte (CPUs und I/O Komponenten) die selbe Transaktion. Die CPU 0 sendet die Original-Anfrage und braucht daher keine physikalische RE-Transmission der Adressen (angezeigt durch den gepunkteten grünen Pfeil). Die hineingehende (incoming) Pfad-Strecke (grün gestrichelt) ist eine feste (fixed) Strecke für alle Geräte auf dem Bus. Die Board-level Address Repeater verwenden ein verteiltes Arbitrations-Schema untereinander, um die Auswahl-Algorithmen, die vom Top-Level Address Repeater benutzt werden, zu interpretieren. 3.6 Snoop Signale Es gibt drei Snoop-Ergebnis Signale: Shared, owned und mapped: Shared wird erstellt von einem System-Gerät, das eine Kopie der Daten hat. Wenn eine Cache-Block nicht shared ist, versetzt das anfragende Gerät den Block in einen Zustand, der es dem Gerät erlaubt, auf diese zu schreiben. 19

20 Owned wird erstellt von einem System-Gerät, das die Daten besitzt und eventuell geändert hat. Es zeigt an, dass die Daten im Speicher zu der Zeit nicht gültig (invalid) sind. Mapped wird erstellt vom Speicher oder I/O Controller, um anzuzeigen, dass die Anfragen zu einer gültigen Speicheradresse oder I/O Gerät geleitet werden. Diese Snoop-Out Signale werden für die gesamte Snooping Coherence Domain durch den Data Switch ASICs auf jedem Board zusammengestellt und kehren zu den System- Geräten 4 Zyklen später zurück als Snoop-In Signale. 3.7 Snoop Tags Jedes Gerät hat zwei Gruppen von Tags: Duale Tags (DTags) und Cache Tags (CTags). Die Cache Tags repräsentieren den aktuellen Zustand der Daten in dem Cache. Die Dualen Tags werden für Snooping und Transaktions-Anfragen verwendet Cache Tags (CTags) Man unterscheidet 5 Cache Tags Zustände: cm: Cache Modified. Der Block ist gültig, exclusive, und (eventuell) dirty im Cache (siehe Status Bedeutung unten). co: Cache Owned. Der Block ist gültig, (eventuell) dirty und (eventuell) shared. ce: Cache Exclusive. Der Block ist gültig, ausschließlich und clean (sauber) im Cache. cs: Cache shared. Der Block ist gültig, (eventuell) shared und clean im Cache. ci: Cache Invalid. Der Block ist ungültig im Cache. Status Bedeutung:. Gültig (valid) bedeutet, dass der Block nützliche Daten beeinhaltet.. Exclusive bedeutet, dass kein anderer Cache eine Kopie von den Daten hat.. Dirty bedeutet, dass die Daten modifiziert bzw. geändert wurden Dual Tags (DTags) Es gibt 4 Dual Tags Zustände: ds: Dual Shared. Der Block ist gültig und clean im Cache. do: Dual Owned. Der Block ist gültig und (eventuell) dirty im Cache. dt: Dual Temporary. Der Block ist gültig, clean und exclusive. Dies ist eine zeitlich begrenzte Form für read to share (RTS) während des Wartens auf Snoop-Input. di: Dual Invalid. Der Block ist ungültig im Cache. Die DTags existieren nicht als separate physikalische Einheit, sind aber stattdessen mit den CTags verbunden in einer einzelnen Gruppe von physikalischen Tags. 20

21 3.8 Fireplane Punkt-zu-Punkt Kohärenz (Point-to-Point Coherency) Fireplane Systeme mit mehr als 24 Prozessoren sind in multiplen Snooping Coherence Domainen organisiert. Ein SSM-Agent in jeder Snooping Coherence Domain befördert Anfragen von nicht-lokalen Daten zum Home SSM-Agent. Home ist dort, wo eine Seite des Speichers physikalisch lokalisiert ist. Der Home SSM-Agent hält die Spur von jedem Beteiligten (Sharer) in der Snooping Coherence Domain oder wo sich der aktuelle Besitzer (Owner) befindet. Das SSM Protokoll benutzt Tags (Memory Tags bzw. MTags), die im Speicher aufbewahrt lagern, um den globalen Kohärenz Status des Speicher-Blocks zu spezifizieren. Die MTags sind in den 8-Bytes des Fehler-Korrektion Codes (ECC) gespeichert, der mit jedem 64-Byte Speicher-Block läuft. Die globale Kohärenz Information wird in den Speicher gestellt, weil die benötigte Anzahl der Snoop Tags zur Darstellung aller Daten, die in anderen Snooping Coherence Domainen gecached sind, zu groß wäre, um in den high speed SRAM zu passen. Stattdessen hat jeder SSM-Agent einen Coherency Directory Cache (CDC), um einen schnelleren Zugriff zu den meisten neueren Kohärenz Informationen zu erhalten. Man unterscheidet drei Zustände der MTags: gm: Global Modified. Der Block ist gültig, exclusive und (eventuell) dirty in dieser Snooping Coherence Domain. Read und Write Operationen sind erlaubt. gs: Global Shared. Der Block ist gültig, clean in der Snooping Coherence Domain und (eventuell) geteilt (shared) von anderen Snooping Coherence Domains. Read Operationen sind erlaubt. gi: Global Invalid. Der Block ist ungültig in dieser Snooping Coherence Domain. Es sind keine Operationen erlaubt. Die MTag Zustände sind eine Ergänzung zu den Snoopy MOESI Zuständen des Blocks. Z.B. um ein Write in einen Block auszuführen, die sowohl modified als auch globalmodified ist, muß ein Prozessor eine Kopie des Blocks haben. Wenn der Block zwar globalmodified aber nicht modified ist, kann sie zu modified überführt werden mit einer Transaktion innerhalb ihrer Snooping Coherence Domain. Kleine und große Fireplane Systeme, die keinen SSM benutzen, haben alle ihre MTags auf globalmodified initialisiert und diese werden nicht verändert. Da globalmodified sowohl Read als auch Write erlaubt, reduziert sich das Protokoll zu einem einfachen Snooping Protokoll. 3.9 Fireplane Address Transaktionen Transaktionen werden zum Fireplane Address Bus gesendet, um Read und Write Operationen zu initialisieren. Alle Adressen beziehen sich auf 64-Byte ausgerichtete (aligned) Blocks, bis auf die 16-Byte I/O Transaktionen. Jede Transaktion beinhaltet 21

22 einen address transfer identifier (ATransID), welcher den Anfrager und die Adressen Transaktion identifiziert Anfragen bezüglich lokaler Daten (Requests for local Data) Diese Transaktionen erhalten Daten von innerhalb einer Snooping Coherence Domain. ReadToShare (RTS). Damit bekommt eine Komponente einen Cache-Block mit einem Read Zugriff. Die Daten werden zurückgeschickt vom aktuellen Besitzer, falls einer existiert, oder vom Home Speicher. WriteBack (WB). Aktualisiert den Speicher mit einem modifizierten Cache-Block. WB wird erzeugt von einem Data Cache Miss, wenn ein dirty Cache-Block zur Ersetzung gezwungen wird, um Platz für andere neu geladene Daten frei zu machen. ReadStream (RS). Liest eine kohärente Kopie des Blocks und entfernt sie von der lokalen Kohärenz Domain. RS wird erzeugt von einer Block Load Instruction. WriteStream (WS). Speichert einen Block im Speicher. WS wird erzeugt von einer Block Store Instruction Daten-Empfang für einen entfernten Anforderer (Get Data for a remote requester) Diese Transaktionen werden benutzt von einem SSM-Agent, um lokale Daten im Namen eines entfernten Requesters zu erhalten. ReadToShareMTag (RTSM). Diese Transaktion wird durchgeführt von einem SSM- Agent, um eine Read Kopie des Blocks für eine andere Snooping Coherence Domain zu bekommen. RTSM ist ähnlich wie ReadToOwn, nur dass anstelle des Ungültigmachens des Blocks in allen anderen Geräten, der Block, der als shared mit den MTags markiert ist, nun in globalshared geändert wird. ReadStreamRemote (RSR). Diese Transaktion wird benutzt vom SSM-Agent, um Daten zu beliefern als Antwort auf ein Remote_ReadStream Wiederausgabe entfernter Reads (Re-issue remote reads) Diese Transaktionen werden benutzt von SSM-Agents, um den Original-Anfrager mit Daten zu versorgen, die von einer anderen Snooping Coherence Domain stammen. ReadToShareRemote (RTSR). Diese Transaktion wird benutzt von einem SSM- Agent, um eine Remote_ReadToShare Transaktion wieder auszuführen. Dies liefert die 22

23 Daten zum Original-Anfrager, welcher zum neuen Besitzer wird, und Übergänge von modified oder owned. Alle anderen lokalen Geräte gehen über zu shared. ReadToOwnRemote (RTOR). Diese Transaktion wird benutzt von einem SSM-Agent, um eine Remote_ReadToOwn Transaktion wieder auszuführen. Dies liefert die Daten zum Original-Anfrager, der zum neuen Besitzer wird, und geht über zu modified oder owned. Alle anderen lokalen Geräte gehen über zu üngültig I/O Transaktionen Diese Transaktionen führen Operationen an I/O Geräten aus. ReadIO (RIO). Liest 16-Byte Block des I/O Speicherraums. WriteIO (WIO). Schreibt 16-Byte Block des I/O Speicherraums. ReadBlockIO (RBIO). Liest 64-Byte Block des I/O Speicherraums. WriteBlockIO (WBIO). Schreibt 64-Byte Block des I/O Speicherraums. Interrupt (Interconnect). Sendet eine Unterbrechung 3.11 Fireplane Data Transfers Daten-Pakete werden transferiert als Antwort auf eine Adressen Transaktion. Der ATransId wird benutzt, um die Antwort der Anfrage anzupassen. Für eine Read Transaktion besteht die Antwort aus einem oder zwei Daten Paketen, die einen entsprechenden Data Transfer Identifier (DTransId) haben. Für eine Write Transaktion besteht die Antwort aus einem entsprechenden Target Transaction Identifier (TTransId) Read Data Transfers Für Read Data Transfers sendet die Quelle der Daten (z.b. ein Cache, CPU oder I/O Gerät) zuerst den DtransId (siehe Punkt und ), zwei Zyklen später gefolgt von den Daten und dem ECC. Der Anfrager (Requester) muß fähig sein, diese Daten anzunehmen, wenn sie eintreffen Write Data Transfers Für Write Data Transfers sendet die Zielkomponente (z.b. ein Cache, CPU oder I/O Gerät) für die Daten einen TTransId und einen Target Identifier (TargId) zum Sender, wenn dieser bereit ist, die Daten anzunehmen. Dann benutzt der Sender die TargId, um die DTransId zu senden, gefolgt von Daten zwei Zyklen später. 23

24 Daten-Pakete Die Daten sind in einem 128-Bit Sub-Block organisiert. Verknüpft mit jedem Sub-Block ist ein 9-Bit ECC, ein 3-Bit MTag und ein 4-Bit MTag ECC. Es gibt zwei Datenpfad- Breiten mit einer Gesamtbreite (Daten + MTag +ECC + MTag + ECC) von 228 Bits (breiter Pfad) und 144 Bits (schmaler Pfad). Ein 64-Byte Daten Transfer besteht aus zwei 32-Byte Paketen für breite Geräte und vier 16-Byte Paketen für schmale Geräte. ReadIO und WriteIO Befehle transferieren 16 Bytes. Die DTransId für alle Daten-Pakete, die der selben Transaktion zugeordnet sind, ist die selbe Beispiel für Fireplane Interconnect Operation Dieser Abschnitt beschreibt die Schritte zur Implementierung eines kohärenten Read-to- Share vom Speicher. Dies erfolgt, um einem Instruction-Cache Miss oder Data -Cache Load Miss zu bearbeiten. Diese Transaktionsabfolgen setzen voraus, dass die Daten laufend eher unmodifiziert im Speicher sind, als dass sie modifiziert (owned) in einem System Geräte Cache vorliegen. Die Diagramme veranschaulichen die aktuelle Interconnect Topologie, die auch ausführlicher in Abb. 3 dargestellt wird Transfer innerhalb einer Snooping Coherence Domain (local Transfers) Dies ist der Fall, wenn der Ziel- Speicherplatz in der selben Snooping Coherence Domain liegt wie der Anfrager (Requester). Die Adresse wird übersendet an den lokalen Address Bus und die System Geräte durchforsten (snoop) ihre Caches. Der 64-Byte Daten Block wird über den Data Switch vom Speicher zum Requester transferiert. Abb. 10: Read to Share Operation mit einer Snooping Coherence Domain 24

25 Address Request (Zyklus 0-2). Die anfragende CPU macht eine ReadToShare Anfrage an ihren Board Address Repeater, welcher die Anfrage zum Top-level Address Repeater hochsendet. Broadcast Address (Zyklus 3-6). Der Top-level Address Repeater wählt diese Anfrage (Request), um diese überall in die Snooping Coherence Domain zu übersenden (broadcast). Er sendet die Anfrage zurück runter zu den Board-level Address Repeatern. Jedes System-Gerät bekommt die Adresse im Zyklus 6. Snoop (Zyklus 7-15). Jedes System-Gerät untersucht seine Kohärenz Tags, um den Status des Cache-Blocks zu bestimmen. Es gibt 3 Snoop-Status Signale: Shared, Owned oder Mapped. Jedes Gerät sendet sein Snoop-Out Ergebnis zu seinem Board Data Switch im Zyklus 11. Jeder Board Data Switch berechnet seine lokalen Snoop Ergebnisse und sendet sie zu jedem anderen Board Data Switch. Jeder Board Data Switch berechnet das Gesamt- Snoop-Ergebnis und sendet das Snoop-In Ergebnis zu seinem System-Gerät im Zyklus 15. Falls das Snoop-Ergebnis einen Treffer (Hit) hat, wird ein Cache-to-Cache Transfer im Zyklus 16 durch das besitzende Gerät initiiert. In diesem Fall würde der Speicher- Anfrage-Zyklus ignoriert werden, es erfolgt also kein Zugriff auf den Speicher. Read from Memory (Zyklus 7-22). Der Ziel-Speicher-Controller (der in der CPU integriert ist) erkennt, dass die Anfrage innerhalb seiner Adressen-Reichweite liegt und initiiert einen Read Zyklus in seiner Speicher-Einheit. In Zyklus 22 wird der Daten-Block vom DIMMs zum lokalen Dual CPU Data Switch gesendet. Transfer Data (Zyklus 23-36). Der Datenblock wird bewegt durch den Board Data Switch, den System Data Switch, den Requester Board Data Switch und den Dual CPU Data Switch. Die vier 18-Byte Teile des Datenblocks kommen in die anfragende CPU im Zyklus Der Address Interconnect braucht 15 System Zyklen (150 ns), um ein Gesamt Snoop Ergebnis zu erhalten und es an die Systemgeräte weiter zu senden. Der DRAM Zugriff wird teilweise gestartet durch den Snoop-Prozess und braucht zusätzlich 7 Zyklen (47 ns), nachdem das Snooping beendet ist. Diese zwei Latenzzeiten haben eine feste Minimalzeit. Der Datentransfer braucht eine variable Anzahl von Clocks, welche davon abhängt, wie viele Data Switch Levels zwischen der Daten-Quelle und der Ziel-Komponente liegen. Er braucht 14 Zyklen (93 ns), wenn sie auf verschiedenen Boards sind, 9 Zyklen (60 ns), wenn sie auf dem selben Board liegen und 5 Zyklen (33ns), wenn sie auf der selben CPU liegen. 25

26 Die durchschnittliche Latenzzeit (von der Adresse aus der CPU raus zu allen Daten in die CPU rein) beträgt 197 ns, wenn sich der Speicher auf dem selben Board befindet, und 240 ns, wenn sich der Speicher auf einem anderen Board befindet Übertragung zwischen Snooping Coherence Domains (Remote Transfers) Dies ist der Fall, wenn die Ziel- Speicherstelle (target memory location) in einer anderen Snooping Coherence Domain als der Requester liegt. Der SSM-Agent auf dem lokalen Adress-Bus des Requesters sendet die Anfrage (Request) zum SSM-Agent in der Home Snooping Coherence Domain über den Adress Crossbar. Der Home SSM-Agent übersendet (broadcasts) die Anfrage (Request) an den Home Address Bus. Entweder der Speicher oder der lokale Cache liefert die Daten. Der Datenblock wird transferriert über den Home Data Switch (Datenverteiler), den Data Crossbar, und den Data Switch des Requesters, um den Requester zu erreichen. Abb. 11: Read to Share Operation zwischen Snooping Coherence Domains Address Request (Takt/Zyklus 0-2). Die anfragende CPU bestimmt aus ihrer lokalen physikalischen Addresse Registern (Local Physical Address Registers), dass die gewünschte Zielspeicherstelle nicht in derselben Snooping Coherence Domain ist. Deswegen macht sie eine Remote_ReadToShare Anfrage (Request) an ihren Board Address Repeater, welcher als Antwort darauf die Anfrage an den Top-level Address Repeater weiter sendet. 26

27 Send address to home SSM-Agent (Zyklus 3-8). Der Top-level Address Repeater arbitriert (verlangt eine Bus Kontroll-Übernahme) für den lokalen Address Bus. Wenn er den Bus bekommen hat, sendet (broadcasts) er eine Remote_ ReadToShare Transaktion auf den lokalen Bus. Die lokalen CPUs und I/O Controllers ignorieren diese Transaktion. Der SSM-Agent des Requesters bestimmt das Home Board aus der physikalischen Adresse. Er sendet den Remote_ReadToShare über den Address Crossbar zum SSM- Agent für das Home Board. Lock Block and Check Coherence (Zyklus 9-11). Der Home SSM-Agent blockiert die Zugriffe auf den Cache-Block, so dass keine anderen Transaktionen in diesem Block stattfinden können. Er prüft seinen Kohärenz Verzeichnis Cache (Coherency Directory Cache). In diesem Fall nehmen wir einen Treffer (Hit) an, welcher anzeigt, dass die angefragte (requested) Speicherstelle nicht owned ist. Falls der Coherency Directory Cache es verfehlt hat (had missed), muss der Home SSM-Agent zusätzlich 16 Sytem Zyklen (106 ns) warten, bis die MTags aus dem Speicher ankommen. Send Expected Response. Der Home SSM-Agent sendet die Anzahl von Slave Antworten (Responses), die erwartet wird (in diesem Fall 0) über den Response Crossbar zum anfragenden SSM-Agent. Der Home SSM-Agent sagt dem Home Data Agent, wann er bereit sein soll, die Daten zum Requester zu schicken. Broadcast Address on Home Bus (Zyklus 12-14). Der Home SSM-Agent arbitriert (arbitrates) für den Home Address Bus. Wenn er den Bus bekommen hat, sendet (broadcasts) er einen ReadToShareMtag. Snoop on Home Bus (Zyklus 15-23). Jedes Systemgerät untersucht seine Kohärenz Tags, um den Status des Cache-Blocks zu bestimmen. Wenn es einen Treffer (Hit) gibt, liefert der besitzende Cache (owning Cache) die Daten, und der Speicher Zyklus wird ignoriert (kein Speicher Zugriff). Read Data from Memory (Zyklus 15-30). Der Memory Controller (welcher sich innerhalb der CPU befindet) für die angefragte (requested) Speicherstelle erkennt, dass die Anforderung in seiner Adressenreichweite (address range) liegt, und führt einen Read Takt in seiner Speichereinheit aus. Diese Daten werden zum lokalen Dual CPU Data Switch gesendet. Transfer Data to Home Data Agent (Zyklus 31-34). Der Datenblock wird zu dem Home Data Agent gesendet. Move Data across Centerplane (Zyklus 35-41). Der Home Data Agent sichert den Datenblock für ein mögliches Mtag update. Es arbitriert für das System Daten 27

28 Crossbar. Es sendet die Daten über den Data Crossbar zum anfragenden Agent mit MTags Set zu globalshared. Transfer Data to Requester (Takt 42-50). Der anfragende Data Agent puffert die Daten bis der lokale Datenpfad zur Verfügung steht. Er benachrichtigt den SSM-Agent des Requesters, dass die Daten angekommen sind. Er arbitriert für den lokalen Datenpfad und sendet die Daten zur anfragenden CPU. Der anfragende SSM- Agent arbitriert für den lokalen Address Bus und gibt die Anfrage zurück als ein ReadToShare-Remote. Count Response. Der anfragende SSM-Agent zählt die erwarteten Antworten (in diesem Fall eine von dem Home SSM-Agent). Er schaut nach Daten-Ankunfts- Benachrichtigung (Data arrival notification) von dem anfragenden Data Agent. Unlock Block. Der anfragende (Requesting) SSM-Agent befiehlt dem Home SSM-Agent über eine Response Crossbar, den Block freizugeben (unlock). Der Home Agent gibt den Block frei (d.h andere Komponenten dürfen wieder auf den Block zugreifen). Update the MTags. Wenn der vorherige Mtag Status nicht globalshared war, müssen die MTags wieder geschrieben werden (re-write). Der Home Agent arbitriert für den Home Adress Bus und übersendet (broadcasts) ein WriteStream. Der Home Data Agent schreibt den Datenblock zurück in den Speicher. Ein Ladevorgang (load) vom Speicher zwischen Snooping Coherence Domains macht vier lokale Adress Bus Transaktionen, eine SSM Anfrage (Request) und zwei SSM Antworten. Es braucht 14 Systemtakte mehr (93 ns) als ein Transfer zwischen Boards innerhalb einer Snooping Coherence Domain. Diese 38%-ige Steigerung in der pin-to-pin Memory Latenzzeit für SSM gegenüber Snooping erlaubt den Spitzen-Bandbreiten der SSM Systeme, sich um eine Spitzen-Bandbreite von 9.6 GBs pro Snooping Coherence Domain zu vergrößern Übertragungsarten - Zusammenfassung Cache-to-Cache Transfers Dies ist der Fall, wenn die Daten in geänderter Form (modified) im Besitz (owned) eines Caches sind In einer Snooping Coherence Domain Das besitzende System-Gerät beansprucht ein Snoop Ergebnis von owned und sendet die Daten direkt zum Requester. Der Speicher Zyklus wird ignoriert. Die pin-to-pin Latenzzeit wird durch 11 System Clocks erhöht (73 ns) um die für einen Ladevorgang aus dem Speicher erforderlichen Zeit. 28

29 Zwischen den Snooping Coherence Domains Ein Drei-Wege Transfer wird ausgeführt. Der Coherency Directory Cache informiert den Home SSM-Agent, welche Snooping Coherence Domain gerade die Daten besitzt. Der Home SSM-Agent sendet dem besitzenden SSM-Agent ein ReadToShareMtag. Der besitzende SSM-Agent läßt die Transaktion auf seinem lokalen Address Bus laufen und liefert die Daten direkt zu dem anfragenden Data Agent. Die Latenzzeit beträgt 21 System Clocks (140 ns) mehr als für einen unowned SSM Transfer und 24 System Clocks (160 ns) mehr als für einen Cache-to-Cache Transfer in ein nicht-ssm System Eine single Snooping Coherence Domain Abb. 12 zeigt die mittelgroßen Server-Gehäuse (cabinet), die alle eine Snooping Coherence Domain haben. Der Zwischen-Board- Interconnect des Sun Fire ist auf den Fireplane Switch Boards zusammengepackt (packaged). Zwei Switch Boards werden in 24-Prozessor-Systemen benutzt. Jedes Switch Board hat einen Address Repeater ASIC und zwei Data Switches ASICs. Abb. 12: Mid und high-end Sun Fireplane Server Die Switch Boards können schnell ausgelagert werden (hot-swapped out), um defaulte Komponenten zu ersetzen. Im acht-prozessor Sun Fire 3800 sind die Fireplane Address 29