DE112008002018T5

DE112008002018T5 - Bereitstellen eines gemeinsam genutzten Inklusiv-Cache bei Mehrkern-Cache-Clustern

Info

Publication number: DE112008002018T5
Application number: DE112008002018T
Authority: DE
Inventors: Krishnakanth Hillsboro Sistla
Original assignee: Intel Corp
Current assignee: Sony Corp of America
Priority date: 2007-07-31
Filing date: 2008-07-21
Publication date: 2010-06-10
Anticipated expiration: 2028-07-22
Also published as: WO2009018005A2; JP2009037615A; WO2009018005A3; US7827357B2; JP5005631B2; US20090037658A1; CN101359310B; DE112008002018B4; CN101359310A

Abstract

Verfahren, das aufweist:
Empfangen angeforderter Daten von einer Systemkopplungsstruktur-Schnittstelle in einem ersten Skalierbarkeitsagenten (SA – Scalability Agent) eines Mehrkernprozessors, der eine Vielzahl von Kern-Cache-Clustern umfasst;
Speichern der angeforderten Daten in einer Zeile eines lokalen Cache eines ersten Kern-Cache-Clusters, der einen anfragenden Kern umfasst; und
Aktualisieren eines Cluster-Feldes und eines Kern-Feldes in einem Vektor eines Tag-Array für die Zeile.

Description

Hintergrund
Mikroprozessoren umfassen im Allgemeinen eine Vielfalt logischer Schaltungen, die auf einer einzigen integrierten Schaltung (IC – Integrated Circuit) aus Halbleitern hergestellt sind. Diese logischen Schaltungen umfassen typischerweise einen Prozessorkern, Speicher und weitere Komponenten. Heutige hochwertige Prozessoren umfassen mehrere Prozessorkerne in derselben IC. Zum Beispiel zeigen Mehrkernprozessoren, so wie Chip-Multiprozessoren (CMPs – Chip Multi-Processors) eine Mehrkernstruktur, die mehrere Prozessorkerne innerhalb einer IC implementiert.
Verbesserte Wirkungsgrade für Silizium bieten nun neue Gelegenheiten, zusätzliche Funktionalität in das Silizium des Prozessors einzubringen. Als ein Beispiel ziehen Anwendungen einen Nutzen aus erhöhter Multi-Threading-Fähigkeit, die durch eine erhöhte Anzahl an Prozessorkernen in demselben Prozessor realisiert werden. Das Leistungsverhalten eines Mehrkernprozessors kann durch Milder von Verzögerungsproblemen bei der Systemkopplungsstruktur und durch Sicherstellen, dass vereinigte Prozessorkerne als ein Cache-Agent erscheinen, optimiert werden, um Probleme der Skalierbarkeit und der Sättigung der Kopplungsstruktur zu vermeiden. Systeme, welche Caches umfassen, die jeweils mit mehreren Kernen verknüpft sind, sind typischerweise als geteilte Caches strukturiert, bei denen jeder Cache als ein unabhängiger Cache-Bereich wirkt. Dies erhöht die Gesamtanzahl an Kohärenzfehlern, was somit die Fehler pro Befehl erhöht. Geteilte Caches verlieren auch an Kapazität aufgrund des Kopierens von gemeinsam genutztem Code/Daten in allen unabhängigen Caches.
Kurzbeschreibung der Zeichnungen
1 ist ein Blockschaubild eines Mehrkernprozessors gemäß einer Ausführungsform der vorliegenden Erfindung.
2 ist ein Blockschaubild eines Prozessors gemäß einer weiteren Ausführungsform der vorliegenden Erfindung.
3 ist ein Ablaufdiagramm eines Verfahrens gemäß einer Ausführungsform der vorliegenden Erfindung.
4 ist ein Ablaufdiagramm eines Verfahrens gemäß einer Ausführungsform der vorliegenden Erfindung.
5 ist ein Blockschaubild eines Multiprozessorsystems gemäß einer Ausführungsform der vorliegenden Erfindung.
Genaue Beschreibung
Ein Protokoll für einen Skalierbarkeitsagenten ermöglicht ein geclustertes Verfahren zum Skalieren der Anzahl von Kernen in einem Prozessor. Bei einem geclusterten Skalierverfahren wird eine Kern-Cache-Einheit als ein Aufbaublock verwendet, und mehrere solcher Einheiten werden vereinigt, um die Anzahl der Kerne in dem Prozessor zu erhöhen. Die Kern-Cache-Einheit kann zwei oder mehr Kerne mit einem geeignet bemessenen, gemeinsam genutzten Cache enthalten. Bei verschiedenen Ausführungsformen können mehrere Kern-Cache-Cluster (hierin als „Cluster” bezeichnet) eines Mehrkernprozessors, die beispielsweise über eine Systemkopplungsstruktur, wie ein Common System Interconnect (CSI) gekoppelt sind, dazu ausgelegt sein, eine Inklusiv-Cache-Struktur für die gesamte Fassung zur Verfügung zu stellen, wobei einzelne Caches aus dem Cluster nicht inklusiv sein können. Der Ausdruck „Kern-Cache-Cluster” wird allgemein als eine modulare Einheit betrachtet, die einen oder mehrere Kerne und einen gemeinsam genutzten Cache aufweist. Core-Cache-Cluster werden als Aufbaublöcke für einen skalierbaren Mehrkernprozessor verwendet.
Gemäß einer Ausführungsform der Erfindung ist das „Protokoll für einen Skalierbarkeitsagenten” ein Kommunikationsmuster, das das Zusammenlegen von Kern-Cache-Clustern erlaubt, die unabhängig voneinander arbeiten, und das die „zierliche” Skalierbarkeit zur Verfügung stellt, bei der die Verantwortlichkeit zum Aufrechterhalten der Speicherkohärenz ungefähr gleich unter den Kern-Cache-Clustern aufgeteilt ist, ungeachtet irgendeiner Zunahme oder einer Abnahme in der Anzahl, während das Protokoll für den Skalierbarkeitsagenten auf Adressbereiche in dem Adressraum-Systemspeicher aufteilbar ist. Die Verzögerungszeiten für den Cache in dem Kern-Cache-Cluster bleiben im Wesentlichen ungeändert, wenn sich die Anzahl der Kerne erhöht.
Ein „Skalierbarkeitsagent” ist Hardware und/oder Software, die den Strom der hinausgehenden und hereinkommenden Transaktionen in eine Fassung verwaltet, welche mit dem Kern-Cache-Cluster verknüpft ist, und die das Protokoll für einen Skalierbarkeitsagenten unterstützt. Gemäß einer Ausführungsform der Erfindung (i) führt der Skalierbarkeitsagent Kern-Cache-Cluster zusammen, so dass sie als ein Cache-Agent erscheinen, (ii) handhabt er die Kohärenz lokaler Caches zwischen Kern-Cache-Clustern auf derselben IC und (iii) unterstützt er die Skalierbarkeit, so dass die Arbeitsabläufe bei einem Kern-Cache-Cluster nicht wesentlich beeinflusst werden, wenn weitere Kern-Cache-Cluster hinzugefügt werden.
Mit Bezug nun auf die 1 ist eine beispielhafte Ausführungsform eines Mehrkernprozessors, so wie einem geclusterten CMP mit einem Skalierbarkeitsagenten, gezeigt. Der Mehrkernprozessor 300 umfasst eine Vielzahl von Kern-Cache-Clustern 310₁ –310_n (allgemein Cluster 310) in Verbindung miteinander über eine Kopplungsstruktur 320 auf dem Chip. Der Mehrkernprozessor 300 steht mit außerhalb befindlichen Einheiten über eine System-Kopplungsstruktur-Schnittstelle 140 und über eine Kopplungsstruktur 180 in Verbindung. Gemäß einer Ausführungsform der Erfindung ist die Kopplungsstruktur 320 auf dem Chip als eine Ring-Kopplungsstruktur ausgelegt, kann jedoch als ein Kopplungsstrukturnetz (z. B. 2D-Netz) ausgelegt sein. Jeder Kern-Cache-Cluster 310 umfasst einen oder mehrere Kerne 330, die einen aus einer Vielzahl von Caches 340₁ –340_N (allgemein Cache 340) gemeinsam nutzen. Die Architektur der Kern-Cache-Cluster 310 kann entsprechend einer Cache-Brückenarchitektur oder einer Architektur für verteilte gemeinsam genutzte Caches sein. Die Transaktionen, mit denen die Kern-Cache-Cluster 310 befasst sind, werden durch entsprechende Skalierbarkeitsagenten (SAs – Scalability Agents) 350₁ –350_n (allgemein Skalierbarkeitsagent 350) wie hiernach beschrieben gesteuert. Entsprechend dieser Architektur ermög licht es der Mehrkernprozessor 300, dass die Verzögerungszeit bei einem ersten gemeinsam genutzten Cache 340₁ im Wesentlichen konstant bleibt, ungeachtet einem Anwachsen der Anzahl der Kerne im Prozessor 300, was sicherstellt, dass das skalare Leistungsverhalten von Threads ohne oder mit begrenzter gemeinsamer Nutzung konstant bleibt.
Ein Prozessor gemäß einer Ausführungsform der vorliegenden Erfindung kann vereinigt werden, um sein Gesamtleistungsverhalten zu verbessern und Prozessorgestaltungen der nächsten Generation zu unterstützen. Wenn zum Beispiel der Kern-Cache-Cluster die Architektur gemäß dem Stil der Cache-Brücke verwendet, kann ein besseres Leistungsverhalten erzielt werden, indem zwei Core-Cache-Cluster (mit 4 Kernen) vereinigt werden, um einen Mehrkernprozessor mit acht Kernen (8 Kerne) zu erzeugen. Auch können zwei Cluster mit 4 Kernen verwendet werden, um bei einer Generation einen Prozessor mit 8 Kernen aufzubauen, einen Prozessor mit 12 Kernen in der nächsten Generation und einen Prozessor mit 16 Kernen in einer anschließenden Generation. Die geeignete Anzahl „N” von Kern-Cache-Clustern 310 und die Anzahl der Kerne in jedem Kern-Cache-Cluster kann festgelegt werden, um das optimale Leistungsverhalten zu erzielen. Dies bietet Flexibilität und die Option, eine einfachere Implementierung zu wählen. Zusätzlich zu den oben angesprochenen Vorteilen ermöglichen die SAs, dass die einzelnen Caches zusammen als ein gemeinsam genutzter Cache der letzten Ebene (LLC – Last Level Cache) arbeiten und ermöglichen, dass Daten, die für jeden Kern-Cache-Cluster geheim sind, in seinem eigenen Cache bleiben, was zu einer geringeren Zeitverzögerung für geheime Daten führt. Somit, weiter in der 1 gezeigt, entsprechen SA-Einheiten 350₁ –350₄ (allgemein SA-Einheiten 350) (N = 4) eindeutig Kern-Cache-Clustern 310 und können bezüglich ihrer Adressen in unabhängige SA-Einheiten 350 aufgeteilt werden, von denen jede für eine Untermenge eines Adressraums verantwortlich ist.
Obwohl es bei der Ausführungsform der 1 so gezeigt ist, dass ein Prozessor enthalten ist, der auf einem einzelnen Chip gebildet ist, kann bei weiteren Ausführungsformen ein Mehrchipgehäuse implementiert werden. Mit Bezug nun auf 2 ist ein Blockschaubild eines Prozessors gemäß einer weiteren Ausführungsform der vorliegenden Erfindung gezeigt. Wie in 2 gezeigt, umfasst ein Prozessor 400, der ein Mehrchip-Prozessorgehäuse sein kann, einen ersten Chip 410₁ und einen zweiten Chip 410₂ , die durch eine Kopplungsstruktur 430 auf dem Gehäuse verbunden sein können, welche eine Punkt-zu-Punkt (PTP – Point-To-Point)-Kopplungsstruktur sein kann. Jeder Chip 410 (allgemein) kann wenigstens einen Kern-Cache-Cluster umfassen, welcher einen Cache 415₁ und 415₂ und eine Vielzahl von Kernen 420 aufweist. Jeder Chip 410 umfasst weiterhin einen Skalierbarkeitsagenten 425₁ und 425₂ . Der Prozessor 400 kann mit weiteren Komponenten aus einem System kommunizieren, wobei ein Paar System-Kopplungsstrukturen 440₁ und 440₂ verwendet wird, von denen beide bei einigen Ausführungsformen PTP-Verbindungen sein können. Natürlich sind andere Implementierungen möglich. Zum Beispiel kann jeder Chip mehrere Kern-Cache-Cluster und so weiter umfassen. Indem der SA auf jedem der Chips implementiert wird, können die Chips an der Kopplungsstruktur verbunden werden, was somit die Anzahl der Kerne verdoppelt. Zusätzlich werden sich die Caches 415₁ und 415₂ nun wie ein gemeinsam genutzter Cache mit der Größe von beiden verhalten, was eine Verbesserung beim Leistungverhalten hervorruft. Zum Beispiel, wenn jeder Chip ein Chip mit 4 Kernen mit 8 Megabyte (M) Cache wäre, dann würde sich der kombinierte Prozessor mit 8 Kernen wie ein Cache mit 16 M verhalten.
Basierend auf derartigen Ausgestaltungen ist ein Skalierbarkeitsagent dazu ausgelegt, das Protokoll für Skalierbarkeitsagenten zum Vereinigen von Kern-Cache-Clustern zu unterstützen, jedoch tritt die Vereinigung als ein einziger Cache-Agent für Einheiten, die zur Kommunikation mit einer System-Kopplungsstruktur gekoppelt sind, in Erscheinung. Der Zweck für das Verdecken der Anzahl der Kern-Cache-Cluster ist ein doppelter. Zunächst mildert das Verdecken Probleme bei der Sättigung der Kopplungsstruktur, die durch wiederholten Verkehr über eine Kopplungsstruktur auf dem Chip (oder Gehäuse) hervorgerufen wird. Zweitens vermeidet das Verdecken die wiederholte Neugestaltung eines Home-Agent. Genauer, wenn jeder Prozessorkern einen Cache-Agent bilden würde, würde ein System mit „N” Clustern und „M” Fassungen als ein Cache-Agentensystem N·M für die Home-Agents in dem System wahrgenommen werden. Der SA arbeitet im Wesentlichen so, dass er die Last der Verantwortlichkeiten für die lokale Kohärenz und für das Verteilen der Kohärenz an die Kern-Cache-Cluster selbst übernimmt. Ansonsten würde jedes Mal, wenn ein Kern-Cache-Cluster abgeändert oder hinzugefügt wird, der Home-Agent neu gestaltet werden müssen. Neben der Funktionalität der verdeckten Vereinigung ist das Protokoll für Skalierbarkeitsagenten für das Handhaben lokaler Kohärenz zwischen Kern-Cache-Clustern auf derselben IC gestaltet.
Bei verschiedenen Ausführungsformen kann, um das Kopieren zu vermeiden, das üblicherweise bei einem geteilten Cache geschieht, exakt eine Kopie jeder Zeile, die in die Fassung gebracht worden ist, aufrechterhalten werden. Da es nur eine Kopie gibt, wird sie sich in einem der Caches des Kern-Cache-Clusters befinden. Um sicherzustellen, dass das Vorhandensein einer Cache-Zeile in all den Kernen in einer Fassung verfolgt wird, kann ein Kern-Bit-Feld in den Cache des Kern-Cache-Clusters gebracht werden. Es gibt zwei Wege, dies zu tun. Jeder Cache kann so aufgebaut werden, dass er Kern-Bits gleich der Gesamtanzahl der Kerne in der Fassung enthält, oder Kern-Bit-Raum kann gespart werden, indem nur erinnert wird, welcher Cluster die Zeile enthält. Somit hat jeder Cache des Kern-Cache-Clusters Kern-Bits gleich der Anzahl der Kerne in dem lokalen Cluster und Cluster-Bits, die verfolgen, ob die Zeile in anderen Cluster in der Fassung vorhanden ist.
Mit Bezug nun auf 3 ist ein Ablaufdiagramm eines Verfahrens gemäß einer Ausführungsform der vorliegenden Erfindung gezeigt. Wie es in der 3 gezeigt ist, kann ein Verfahren 10 verwendet werden, um einlaufende Daten handzuhaben, wenn eine Cache-Zeile in eine Prozessorfassung gebracht worden ist. Wie es in der 3 gezeigt ist, kann das Verfahren 10 damit beginnen, angeforderte Daten von einer System-Kopplungsstruktur-Schnittstelle zu empfangen (Block 20). Zum Beispiel kann eine derartige Cache-Zeile von einem SA empfangen werden, der die Daten angefordert hat. Die Daten können dann in einer Zeile eines lokalen Cache gespeichert werden, der mit dem anfragenden Kern verknüpft ist (Block 30).
Weiter noch mit Bezug auf die 3 können als nächstes ein Cluster-Bit und ein Kern-Bit in einem Vektor eines Tag-Array für diese Zeile aktualisiert werden (Block 40). Diese Aktualisieren gibt somit an, dass die Zeile in dem Cluster vorhanden ist und von dem gegebenen Kern angefragt oder auf sie zugegriffen worden ist. Dann können die Daten selbst dem anfragenden Kern zur Verfügung gestellt werden (Block 50). Somit wird nur eine Kopie der Daten in der Fassung gehalten (Block 60). Das heißt, nur die einzelne Zeile für diese Daten kann in der Fassung vorhanden sein, obwohl auf sie von Kernen des Clusters, in denen sie gespeichert ist, oder von Kernen anderer Cluster zugegriffen werden kann. Um sicherzustellen, dass Cache-Zeilen, die für jeden Kern geheim sind, in ihrem eigenen Cluster wohnen, ist die getroffene Strategieentscheidung die, den ersten Ladezugriff die Zeile in seinem eigenen Cluster füllen zu lassen. Somit werden Zeilen ohne irgendwelche vorbestimmte Adressen-Hash-Strategien verteilt. Ein größerer Vorzug wird der Lokalität gegenüber der zufälligen Verteilung gegeben. Basierend auf dieser selben Strategie werden gemeinsam genutzte Daten zufällig basierend auf dem ersten Zugriff verteilt. Im Mittel werden gemeinsam genutzte Daten von jedem Kern in der Fassung gleich weit entfernt sein. Da es nur eine Kopie jeder Zeile gibt, ist jeder Cluster nicht für sich allein inklusiv. Jedoch ist die Fassung inklusiv.
Für jede Cache-Zeile in der Fassung gibt es einen „Eigentümer”-Cache. Dies ist der Cluster-Cache, der die Zeile enthält. Er enthält den Fassung-Ebene-Zustand der Zeile und verfolgt die Kern-Bits und Cluster-Bits für die Zeile. Snooping über das Cluster und einlaufende Ströme werden derart gestaltet, dass Snoop-Ströme schließlich Kerne und Cluster snoopen, die von dem Eigentümer-Cache angegeben werden. Write-back-Ströme von dem Kern werden so gestaltet, dass der Schreibvorgang schließlich den Eigentümer-Cache aktualisiert. Somit ist auf der Ebene der Fassung die Inklusivität eingehalten.
Die Information, die in einem Tag-Array eines Kern-Cache-Cluster gespeichert ist, wird erweitert, so dass sie zusätzliche Information über die Anzahl der Cluster in der Fassung umfasst. Ein Bit Local_Data wird zu einer Schlussnachricht für jede Transaktion hinzugefügt.
Wenn die Schlussnachricht von außerhalb der Fassung zurückkehrt, wird das Bit zwangsweise auf Null gesetzt. Für Schlussnachrichten, die von dem SA zurückgegeben werden, kann dieses Bit entweder Null oder Eins sein. Wenn das Bit Local_Data Eins ist, ist dies eine Angabe für den Nachfragenden, dass die Zeile durch einen Cluster auf dem Chip zurückgegeben wird und nicht in den Cache des Anfragenden gefüllt wird. Wenn das Bit Local_Data Null ist, impliziert dies, dass die Zeile in den Cache des Anfragenden gefüllt werden kann. Ein Bit Local_Snp ist auf der Snoop-Schnittstelle zwischen dem SA und dem Kern-Cluster definiert. Es wird verwendet, um dem Cluster anzugeben, ob der Snoop von einer Transaktion, die auf der vorliegenden Fassung erzeugt worden ist, herrührte oder nicht. Ein Bit SNP_all wird auf der Snoop-Schnittstelle zwischen dem SA und dem Kern-Cluster definiert. Wenn es gesetzt ist, gibt es dem Cluster an, dass unabhängig vom Nachschlagen in seinem Cache es dazu führt, dass alle Kerne in dem Cluster gesnoopt werden müssen, mit der Ausnahme, dass der Cluster ein Eigentümer-Cluster für die Zeile ist. Wenn es nicht gesetzt ist, kann der Cluster mit den üblichen Regeln des inklusiven Snooping fortfahren. Cluster-Bits werden dem SA vom Eigentümer-Cluster bezeichnet, um anzuzeigen, welche Cluster gesnoopt werden müssen. Diese würden bei einem Lesevorgang angegeben, welcher einen lokalen Cache trifft und einen Snoop über die Cluster erfordert, oder bei einem Snoop, der die Zeile in dem Eigentümer-Cluster trifft. Cluster-Bits werden auf Anfrage/Antworten vom Kern-Cache-Cluster an den SA angegeben. Ein Bit für einen Cross-Snoop (xsnp_Only) wird auf der Schnittstelle von dem Kern-Cache-Cluster zu dem SA angegeben. Wenn es gesetzt ist, gibt der Cluster an, dass er der Eigenturner-Cluster ist und ein Snoop über den Cluster erforderlich ist, dass jedoch für die gegenwärtige Anfrage keine externe Anfrage erforderlich ist. Cluster-Bits werden immer angegeben, wenn das Bit xsnp_Only gesetzt ist. Ein Bit Rd Miss wird verwendet, um anzugeben, dass die vorliegende Anfrage vom Kern-Cache-Cluster an dem SA ein Fehler des lokalen Cache ist. Dies impliziert, dass der SA nicht nur einen Snoop über den Cluster ausführen muss, es kann auch sein, dass es nötig ist, eine externe Anfrage zu senden. Ein Bit Wr Miss wird verwendet, um zwischen Räumungen und einem Write back-Vorgang, welcher den lokalen Cache verfehlt, unterscheidet. Wenn es bei einer Write-back-Transaktion gesetzt ist, gibt es an, dass der vorliegende Write-back-Vorgang ein Write-back-Vorgang ist, der den lokalen Cache verfehlt hat. Wenn das Bit Wr_Miss nicht gesetzt ist, dann werden dem SA Cluster-Bits angezeigt. Ein zusätzliches Bit, das Bit My_own, ist auf der Schnittstelle zwischen dem Kern-Cluster und dem SA auf einer Snoop-Antwort vorhanden. Wenn das Bit gesetzt ist, gibt der Cluster dem SA an, dass er der Besitzer für die Zeile ist und die Cluster-Bits als gültig angegeben sind.
Da der Cache in jedem Kern-Cache-Cluster ein gemeinsam genutzter Inklusiv-Cache ist, enthält der Cache Kern-Bits, die in einem Vektor vorhanden sind, welcher in dem Tag-Array des Cache gespeichert sind, die angeben, welche Kerne in dem Cluster möglicherweise die aktuelle Zeile enthalten könnten. Es werde der Fall betrachtet, dass n Kern-Cache-Cluster vorhanden sind, wobei jeder Cluster i Kerne enthält, welche die SA-Architektur verwenden, so dass die Gesamtanzahl von Kernen in der Fassung n·i ist. Der Cache in jedem Kern-Cache-Cluster wird einen Vektor aus Kern-Bits enthalten, der i Bit breit ist. Der Vektor der Kern-Bits in jedem Kern-Cache-Cluster ist i + n breit. Die ersten i Bits werden als Bits des lokalen Kerns bezeichnet und die nächsten n Bits sind als Cluster-Bits bekannt. Bits des lokalen Kerns geben an, welcher Kern auf den Cache zugegriffen hat. Cluster-Bits geben an, welche Cluster die aktuelle Zeile enthalten.
Wie es hiernach beschrieben wird, können Lese/Schreib/Snoop-Ströme abgeändert werden, um die Kohärenz zu erhalten, wobei sie den zuvor beschriebenen Grundsätzen entsprechen. Die Schnittstelle zwischen dem SA und den Kern-Cache-Clustern ist so gestaltet, dass sie bei der Implementierung der oben beschriebenen Strategien unterstützt. Zusätzlich werden LLC-Ströme abgeändert, um Treffer, die Snoops in anderen Clustern erfordern, Fehler und Writeback-Vorgänge; (WBs – Write Backs), die den LLC verfehlen (sie können dies, da sich die Zeile in einem LLC in einem anderen Cluster befinden könnte), behandeln. Die Strategien sind so gestaltet, dass sie Vervielfältigung vermeiden und eine einzige Kopie jeder Zeile in der Fassung halten.
Mit Bezug nun auf die 4 ist ein Ablaufdiagramm eines Verfahrens gemäß einer Ausführungsform der vorliegenden Erfindung gezeigt. Genauer, wie in der 4 gezeigt, kann ein Verfahren 100 verwendet werden, um Cache-Verwaltungsstrategien für Anfragen zu veranschaulichen, die in einen lokalen Cache treffen, der mit einem anfragenden Kern verknüpft ist, und einen Fehler in einem derartigen Cache. Nun mit Bezug auf die 4 kann das Verfahren 100 so beginnen, dass festgestellt wird, ob eine Kern-Anfrage in den lokalen Cache trifft (Diamant 120). Wenn eine Anfrage den lokalen Cache trifft und nur die lokalen Clusters-Bits gesetzt sind (wie im Diamanten 125 festgestellt), könnte ein lokaler Cross-Snoop ausgegeben werden oder die Zeile kann an den anfragenden Kern ohne Cross-Snoops zurückgegeben werden (Block 130). Wenn ein lokales Cluster-Bit zusammen mit einigen anderen Cluster-Bits gesetzt ist (oder nur andere Bits gesetzt sind), geht die Steuerung zum Diamanten 135 über. Wenn die aktuelle Anfrage ein Lesevorgang ist, dann ist die aktuelle Anfrage ein Treffer, keine Anfrage an den SA wird benötigt. Somit werden geeignete lokale Kern- und lokale Cluster-Bits gesetzt, bevor Daten an den Kern geliefert werden (Block 140). Ansonsten, wenn die aktuelle Anfrage eine Anfrage nach Eigentümerschaft (RFO – Request for Ownership) ist, dann wird eine fehlerhafte Anfrage mit gesetztem Bit xsnp_only an den geeigneten SA gesendet, der auf einem Adressen-Hash basieren kann (Block 145). Es ist möglich, dass, da dass xsnp an den anderen Cluster durch den SA ausgegeben worden ist, neue Daten ankommen können. Sobald der xsnp beendet ist, werden zwischengespeicherte Daten oder neue Daten an den anfragenden Kern geliefert. Dann werden sie in den lokalen Cache gefüllt, wobei nur das lokale Cluster-Bit und das lokale Kern-Bit des anfragenden Kerns gesetzt sind (wieder im Block 140).
Wenn stattdessen am Diamanten 120 ein Fehler festgestellt wird, werden die folgenden Cache-Fehlerstrategien verfolgt. Eine Fehleranfrage wird an den SA ausgegeben, wobei das Bit xsnp_only rückgesetzt wird (Block 150). Wenn der SA die Transaktion abschließt, wird er ein Bit schicken, das local_data genannt wird. Wenn das Bit local_data gesetzt ist (wie es im Diamanten 155 festgestellt wird), dann werden Daten an den Kern geliefert und nicht in den lokalen Cache gefüllt (Block 160). Wenn das Bit local_data nicht gesetzt ist, dann werden Daten an den Kern geliefert, und die Zeile wird in den lokalen Cache gefüllt, und das lokale Cluster- und das lokale Kern-Bit des anfragenden Kerns werden gesetzt (Block 165). Man bemerke, dass der SA das Bit local_data verwendet, um die Vervielfältigung von Daten in anderen Caches zu steuern. Obwohl es bei dieser besonderen Implementierung in der Ausführungsform der 4 gezeigt ist, ist der Umfang der vorliegenden Erfindung in dieser Hinsicht nicht beschränkt.
Aus der Perspektive der Fassung her können Transaktionen in zwei breite Klassen klassifiziert werden: auslaufende Transaktionen und hereinkommende Transaktionen. Für beide Klassen der Transaktionen spielt der Skalierbarkeitsagent die Rolle eines Snooping-Agenten auf dem Chip und des Zusammenführers für Snoop-Antworten. Die skalierbare Vereinigungsarchitektur für Kern-Cache-Cluster, die durch Ausführungsformen der vorliegenden Erfindung dargestellt wird, kann bei Prozessoren mit größeren Anzahlen von Kernen verwendet werden, indem Kern-Cache-Cluster vereinigt werden. Die Snooping-Funktionalität auf dem Chip bei den Skalierbarkeitsagenten stellt einen Cache-Cache-Übergang zwischen Kern-Cache-Clustern auf demselben Chip mit einer niedrigen Verzögerungszeit sicher. Man bemerke, dass die Verzögerungszeit der Kopplungsstruktur auf dem Chip und die Bandbreite nicht kritisch sind, da der Verkehr von den Prozessorkernen durch einen gemeinsam genutzten Cache gefiltert wird.
Bei einer Ausführungsform kann den folgenden Räumungsstrategien gefolgt werden. Bei der Räumung eines lokalen Cache werden Cluster-Bits an den SA zusammen mit der Räumungsanfrage geschickt (die eine Nachricht vom Typ WB ist). Zusätzlich wird das Bit wr_miss auf Null gesetzt. Den folgenden Schreibfehlerstrategien wird gefolgt. Es ist möglich, dass ein WB von dem Kern den lokalen Cache verfehlen wird. Dies kann sein, weil die Zeile in einem anderen Kern-Cache-Cluster liegen könnte. Wenn dies geschieht, wird das Schreiben an den SA lediglich als eine Räumung ausgegeben, jedoch wird das Bit WR_miss gesetzt. Den folgenden Snoop-Verarbeitungsstrategien wird gefolgt. Wenn ein ankommender Snoop empfangen wird, werden die Bits snp_all, local_snp überprüft. Wenn das Bit snp_all gesetzt ist, gibt dies an, dass der Snoop an alle Kerne gesendet werden muss, unabhängig von den Ergebnissen beim gemeinsam genutzten Cache. Man bemerke, dass ein Eigentümer-Cache niemals einen Snoop empfangen wird, wenn das Bit snp_all gesetzt ist. Wenn das Bit local_snp gesetzt ist und der aktuelle Snoop in den lokalen Cache trifft, dann werden die geeigneten lokalen Kerne gesnoopt und antworten dem SA mit geeigneten Antworten, Cluster-Bits und dem gesetzten Bit my_own. Die Cluster-Bits du die Kern-Bits können geeignet aktualisiert werden. Wenn das Bit local_snp gesetzt ist und der aktuelle Snoop ein Fehler ist, können Antworten zurückgegeben werden, wobei das Bit my_own rückgesetzt wird. Der SA ist zum Durchführen des Snooping auf dem Chip verantwortlich. Zusätzlich zum Snoopen seines Kern-Cache-Clusters als ein Ergebnis hinausgehender und hereinkommender Anfragen, arbeitet er mit den Clustern, um sicherzustellen, dass es nur eine einzige Kopie jeder Zeile in der Fassung gibt. Er löst auch Konflikte zwischen Cluster, obwohl die Konfliktlösung über den Umfang hier hinausgeht, es wird angenommen, dass alle Transaktionen konfliktfrei sind.

Verschiedene hinausgehende Transaktionen mit einem Clustertreffer sind in Tabelle 1 gezeigt, in der SA-Ströme dargestellt werden, indem zwei SA-Einheiten SA0 und SA1 und zwei Kern-Cache-Cluster CC0 und CC1 verwendet werden, wobei eine modifiziert, exklusiv, gemeinsam genutzt, ungültig (MESI – Modified Exclusive Shared Invalid)”-Cache-Kohärenzstrategie verwendet wird. Lokale Cross-Snoops sind nicht gezeigt, nur die Ströme durch den SA werden beschrieben. Tabelle 1

Transaktionstyp	Zustand des lokalen Cache	Lokale Kern-Bits	Andere Cluster-Bits	Zustand anderer Cluster	Antwort anderer Cluster
RdCode/RdDate/RdInvlOwn	M, E, S	Nur	Keine	Keiner	Keine
RdCode/RdData	M, E, S	Einige	Einige	S, I,	Keine
RdInvlOwn	M, E	Einige	Einige	S, I	RspI
RdInvlOwn	S	Einige	Einige	S, I	RspI
RdCode/RdData	M, E	Keine	Nur Eines	I	RspI
RdCode/RdData	M, E	Keine	Nur Eines	E, S	RspS
RdCode/RdData	M, E	Keine	Nur Eines	M	RspFwdI
RdInvlOwn	M, E	Keine	Nur Eines	E, S, I	RspI
RdInvlOwn	M, E	Keine	Nur Eines	M	RspFwdI
RdCode/RdData	S	Keine	Einige/Nur Eines	S, I	Keine
RdCode/RdData	M, E	Keine	Einige	Keiner	Keine
RdInvlOwn	S	Keine	Einige	S, I,	RspI
RdInvlOwn	M, E	Keine	Einige	S, I	RspI
Write	M, E	Nur Eines	Keine	Keiner	Keine

Mit Bezug auf Tabelle 1 sind ein Lese/Invalidier/Eigene Transaktion (RdInvlOwn)-Treffer M, E in CC0, einige lokale Kern-Bits und einige weitere Cluster-Bits gesetzt. Dies impliziert, dass die Zeile in anderen Kernen und Clustern entweder S oder I sein kann. Derselbe Strom gilt, wenn ein oder mehrere weitere Cluster-Bits gesetzt sind, keine lokalen Kern-Bits gesetzt sind, und der Zustand der weiteren Cluster-Cache-Zeile E/S/I ist. CC0 wird eine Fehleranfrage an SA0 senden, wobei das Bit xnp_only auf 1 gesetzt ist und die Cluster-Bits auf 11 gesetzt sind. CC1 wird seinen Cache verfehlen, jedoch wird er alle seine Kerne snoopen und mit RspI und my_copy auf 0 gesetzt antworten. SA0 erhält eine Invalidier-Antwort (RspI) von CC1 mit my_copy auf 0 gesetzt. Er wird ein vollständiges GntE_Cmp an CC0 senden, wobei local_data auf Null gesetzt ist. Da local_data gesetzt ist und dieses eine Trefferanfrage ist, werden Daten an den Kern geliefert und das Cluster-Bit wird für CC1 im Cache rückgesetzt.
Weiter mit Bezug auf die Tabelle 1 sei angenommen, dass die Transaktion RdInvlOwn S trifft. Einige oder keines der lokalen Kern-Bits ist/sind gesetzt, ein oder mehrere andere Cluster-Bits sind gesetzt. Dies ist im Wesentlichen ein Fassungsfehler und die Fassungsfehleranfrage wird gesendet, nachdem der Fassungszustand gereinigt ist. CC0 wird eine Fehleranfrage an SA0 senden, wobei das Bit xnp_only auf 0 gesetzt ist und die Cluter-Bits auf 01 gesetzt sind. SA0 überprüft die Cluster-Bits und sendet einen Snoop an CC1, wobei local_snp gesetzt ist und snp_all auf 1 gesetzt ist. CC1 wird seinen Cache verfehlen, wird jedoch alle seine Kerne snoopen und mit RspI und my_copy auf 0 gesetzt antworten. SA0 erhält die RspI von CC1, wobei my_copy auf 0 gesetzt ist. Er wird dann eine Quellensendung auf einer System-Kopplungsstruktur senden. Schließlich wird Heimlogik einen Abschluss an den anfragenden Cluster senden. Da local_data auf 0 gesetzt ist und dies eine Fehleranfrage ist, werden Daten an den Kern geliefert, und die Zeile wird in den Cache 0 gefüllt. Die Cluster-Bits werden auf 10 initialisiert und geeignete Kern-Bits werden gesetzt.
Mit Bezug auf Tabelle 1 trifft eine Transaktion read code/data (RdCode/RdData) M, E in CC0. Nur genau ein weiteres Cluster-Bit ist gesetzt. Der Zeilenzustand in dem anderen Cluster ist I. CC0 wird eine Fehleranfrage an SA0 senden, wobei das Bit xnp_only auf 1 gesetzt ist und die Cluster-Bits auf 01 gesetzt sind. SA0 prüft die Cluster-Bits und sendet einen Snoop an CC1 mit gesetztem local_snp und auf 1 gesetztem snp_all. CC1 wird seinen Cache verfehlen, wird jedoch alle seine Kerne snoopen und mit RspI und my_copy auf 0 gesetzt antworten. SA0 erhält das RspI von CC1 mit my_copy auf 0 gesetzt. Er wird ein vollständiges GntE_Cmp an CC0 schicken, wobei local_data auf Null gesetzt ist. Da local_data gesetzt ist und dies eine Trefferanfrage ist, werden Daten an den Kern geliefert, und das Cluster-Bit wird für CC1 im Cache rückgesetzt.
Mit Bezug auf Tabelle 1 trifft eine Transaktion RdCode/RdData M, E in CC0. Nur genau ein weiteres Cluster-Bit ist gesetzt. Der Zeilenzustand in dem anderen Cluster ist E, S. CC0 wird eine Fehleranfrage an SA0 senden, wobei das Bit xnp_only auf 1 gesetzt ist und die Cluster-Bits auf 11 gesetzt sind. SA0 prüft die Cluster-Bits und senden einen Snoop an CC1 mit gesetztem local_snp und auf 1 gesetztem snp_all. CC1 wird seinen Cache verfehlen, wird jedoch alle seine Kerne snoopen und mit RspS und my_copy auf 0 gesetzt antworten. SA0 empfängt RspS von CC1, wobei my_copy auf 0 gesetzt ist. Er wird ein vollständiges GntS_Cmp an CC0 senden, wobei local_data auf 0 gesetzt ist. Da local_data gesetzt ist und dies eine Trefferanfrage ist, werden Daten an den Kern geliefert und die lokalen Cluster- und lokalen Kern-Bits werden für die Zeile gesetzt.
Mit Bezug auf Tabelle 1 trifft eine Transaktion RdCode/RdData/RdInvlOwn M, E in CC0. Nur genau ein weiteres Cluster-Bit ist gesetzt. Der Zeilenzustand in dem anderen Cluster ist M. CC0 wird eine Fehleranfrage an SA0 senden, wobei das Bit xnp_only auf 1 gesetzt ist und die Cluster-Bits auf 01 gesetzt sind. SA0 überprüft die Cluster-Bits und sendet einen Snoop an CC1, wobei local_snp gesetzt ist und snp_all auf 1 gesetzt ist. CC1 wird seinen Cache verfehlen, wird jedoch alle seine Kerne snoopen und mit RspFwdI und my_copy auf 0 gesetzt antworten. SA0 empfängt RspFwdI von CC1 mit my_copy auf 0 gesetzt. Er wird ein vollständiges GntE_Cmp an CC0 senden, wobei local_data auf 0 gesetzt ist. Da local_data gesetzt ist und dieses eine Trefferanfrage ist, werden Daten an den Kern geliefert und das lokale Cluster-Bit und das geeignete lokale Kernbit für diese Zeile gesetzt.

Gezeigt in Tabelle 2 hiernach sind Beispiele hinauslaufender Transaktionen bei einem Clusterfehler gemäß einer Ausführungsform der vorliegenden Erfindung. Tabelle 2

Transaktionstyp	Zustand des entfernten Cache	Kern-Bits des entfernten Cache	Andere Cluster-Bits des entfernten Cache	Zustand anderer Cluster	Antwort anderer Cluster
RdCode/RdDate/RdInvlOwn	I	Keines	Keines	Keiner	Keine
RdCode/RdData	M, E, S	Nur	Keines	Keiner	Keine
RdInvlOwn	M, E	Nur	Keines	Keiner	Keine
RdInvlOwn	S	Nur	Keines	Keiner	Keine
RdCode/RdData	M, E	Keines	Nur Eines	I	RspI
RdCode/RdData	M, E	Keines	Nur Eines	E, S	RspS
RdCode/RdData	M, E	Keines	Nur Eines	M	RspFwdI
RdInvlOwn	S	Keines	Nur Eines	S, I	RspI
RdInvlOwn	M, E	Keines	Nur Eines	E, S, I	RspI
RdInvlOwn	M, E	Keines	Nur Eines	M	RspFwdI
RdCode/RdData	M, E, S	Keines	Einige	S, I	RspS
RdInvlOwn	S	Keines	Einige	S, I	RspI
RdInvlOwn	M, E	Keines	Einige	S, I	RspI
RdCode/RdData	M, E, S	Einige	Einige	S, I	RspI/RspS
RdInvlOwn	S	Einige	Einige	S, I	RspI
RdInvlOwn	M, E	Einige	Einige	S, I	RspI
Schreibfehler	M, E	Keines	Nur Eines	Keiner	Keine
Cache-Räumung	M	Nur Eines	Nur Eines	Keiner	Keine

Mit Bezug auf Tabelle 2 sei ein Fehler beim lokalen Cluster und ein Fehler bei einem Fern-Cluster angenommen. In diesem Fall ist eine externe Transaktion erforderlich. CC0 wird eine Fehleranfrage an SA0 senden, wobei das Bit xnp_only of 0 gesetzt ist und das Bit rd_miss gesetzt ist. Wenn rd_miss gesetzt ist, sind die Cluster-Bits nicht relevant, SA0 überprüft die Cluster-Bits und sendet einen Snoop an CC1, wobei local_snp gesetzt ist und snp_all auf 0 gesetzt ist. CC1 wird seinen Cache verfehlen, da snp_all auf 0 gesetzt ist. Er wird seinen Kern nicht snoopen, sondern ein RspI an den SA zurückgeben, wobei my_copy auf Null gesetzt ist. Der SA0 erhält die RspI von CC1, wobei my_copy auf 0 gesetzt ist. Dies bringt mit sich, dass CC1 die Zeile nicht hatte. Er wird dann eine Quellensendung auf der System-Kopplungsstruktur senden. Schließlich wird Heim-Logik einen Abschluss an den anfragenden Cluster senden. Da local_data auf Null gesetzt ist und dies eine Fehleranfrage ist, werden die Daten an den Kern geliefert und die Zeile wird in den Cache0 gefüllt. Die Cluster-Bits werden auf 10 initialisiert und geeignete Kern-Bits werden gesetzt.
Mit Bezug auf Tabelle 2 hat ein lokaler Cluster RdCode/Rd Data einen Fehler und der ferne Cluster M/E/S, wobei nur sein lokales Kern-Bit gesetzt ist und keine weiteren Cluster-Bits gesetzt sind. CC0 wird eine Fehleranfrage an SA0 senden, wobei das Bit xnp_only auf 0 gesetzt ist und das Bit rd_miss gesetzt ist. Der SA0 überprüft die Cluster-Bits und sendet einen Snoop an CC1, wobei local_snp gesetzt ist und snp_all auf 0 gesetzt ist. CC1 wird einen Treffer in seinem Cache haben. Er wird seine lokalen Kern-Bits überprüfen und die geeignete Verarbeitung beenden. Dann wird er mit RspFwdS an SA0 antworten und Daten direkt an den Anfrager senden. Das Cluster-Bit von CC0 wird in CC1 gesetzt. Zusammen mit der RspFwdS wird das Bit my_copy gesetzt und die Cluster-Bits werden an SA0 versandt. Der SA0 empfängt die RspFwdS zusammen mit dem gesetzten my_copy. Er überprüft die Cluster-Bits von CC1 und entscheidet, ob er die anfragenden/anderen Cluster snoopen muss. In diesem Fall sind keine weiteren Snoops nötig. Er sendet ein Cmp an CC0, wobei local_data auf 1 gesetzt ist. CC0 wird überprüfen, dass local_data gesetzt ist, er wird die Daten an den anfragenden Kern senden und wird sie nicht in seinen Cache füllen.
Mit Bezug weiter auf Tabelle 2 verfehlt eine Transaktion RdInvlOwn in dem lokalen Cluster, entfernter Cluster M/E, wobei nur seine lokalen Kern-Bits gesetzt sind und keine anderen Cluster-Bits gesetzt sind. CC0 wird eine Fehleranfrage an SA0 senden, wobei das Bit xnp_only auf 0 gesetzt ist und das Bit rd_miss gesetzt ist. Der SA0 überprüft die Cluster-Bits und sendet einen Snoop an CC1, wobei local_snp gesetzt ist und snp_all auf 0 gesetzt ist. CC1 wird einen Treffer in seinem Cache haben, er wird seine lokalen Kern-Bits prüfen und die geeignete Verarbeitung abschließen. Dann wird er mit RspFwdI an SA0 antworten und Daten direkt an den Anfrager senden. Das Cluster-Bit von CC0 wird in CC1 gesetzt. Zusammen mit der RspFwdI wird das Bit my_copy gesetzt und die Cluster-Bits werden an den SA0 verschickt. Der SA0 erhält die RspFwdI zusammen mit dem gesetzten my_copy. Er überprüft die Cluster-Bits von CC1 und entscheidet, ob er die anfragenden/anderen Cluster snoopen muss. In diesem Fall sind keine weiteren Snoops nötig. Er sendet ein Cmp an CC0, wobei local_data auf 1 gesetzt ist. CC0 wird überprüfen, dass local_data gesetzt ist, er wird Daten an den anfragenden Kern liefern und sie nicht in seinen Cache füllen.
Mit Bezug noch auf die Tabelle 2 hat eine Transaktion RdInvlOwn einen lokalen Clusterfehler, entfernter Cluster S, wobei nur seine lokalen Kern-Bits gesetzt sind und keine weiteren Cluster-Bits gesetzt sind. CC0 wird eine Fehleranfrage an SA0 senden, wobei das Bit xnp_only auf 0 gesetzt wird und das Bit rd_miss gesetzt ist. Der SA0 überprüft die Cluster-Bits und sendet. einen Snoop an CC1, wobei local_snp gesetzt ist und snp_all auf 0 gesetzt ist. CC1 wird einen Treffer in seinem Cache haben, er wird seine lokale Kern-Bits prüfen und die geeignete Verarbeitung abschließen. In diesem Fall wird die Zeile ungültig gemacht. Dann wird er mit RspI an den SA0 antworten. Zusammen mit der RspI wird das Bit my_copy gesetzt und die Cluster-Bits werden an den SA0 geschickt. Der SA0 erhält die RspI zusammen mit den gesetzten my_copy. Er überprüft die Cluster-Bits von dem CC1 und entscheidet, ob er die anfragenden/andere Cluster snoopen muss. In diesem Fall sind keine weiteren Snoops nötig. Da die Zeile in der Fassung ungültig ist, sendet er einen Fehler für eine Quellenrundsendung. Schließlich wird die Systemdomäne Daten an CC0 liefern. Local_data ist nicht gesetzt. CC0 wird überprüfen, ob local_data gesetzt ist, er wird Daten an den anfragenden Kern liefern und die Zeile in seinen Cache füllen. Das geeignete Kern-Bit und lokale Cluster-Bits werden gesetzt.
Noch mit Bezug auf Tabelle 2 geschieht bei RdCode/RdData in lokaler Clusterfehler, entferntes Cluster M/E, ohne dass lokale Kern-Bits gesetzt sind. Nur das Cluster-Bit des anfragenden Clusters ist gesetzt. RspI/RspS. Dies ist ein spezieller Fall, der etwas erfordert, was als ein Aufräume-Snoop beschrieben werden kann. In der ersten Phase, da der SA nicht weiß, welcher Cluster der Eigentümer ist, sendet er einen Snoop an alle Cluster, wobei das Bit snp_all rückgesetzt ist. Nur ein Cluster wird den Snoop treffen (der Eigentümer-Cluster), und der Rest wird insgesamt verfehlen. Der Eigentümer-Cluster wird eine Snoop-Antwort mit Cluster-Bits für die Zeile zurücksenden, und das Bit my_own wird bei der Antwort gesetzt. Wenn der SA die Cluster-Bits empfängt, gibt er wieder Snoops aus, wobei das Bit snp_all für alle Cluster gesetzt ist, für die das Cluster-Bit gesetzt ist. Dieser Snoop ist der Aufräum-Snoop, der alle Cluster reinigt, die die Zeile enthalten können. Sobald der Aufräume-Snoop beendet ist, wird dem anfragenden Cluster ein Beendet angegeben. Der CC0 wird eine Fehleranfrage an den SA0 senden, wobei das Bit xnp_only auf 0 gesetzt ist und das Bit rd_miss gesetzt ist. Wenn rd_miss gesetzt ist, sind die Cluster-Bits nicht relevant. Der SA0 überprüft die Cluster-Bits und sendet einen Snoop an den CC1, wobei local_snp gesetzt ist und snp_all auf 0 gesetzt ist. Der CC1 wird einen Treffer in seinem Cache haben, er wird seine lokalen Kern-Bits prüfen und die geeignete Verarbeitung beenden. Er wird mit RspFwdI an den SA0 antworten. Die Daten werden an den Anfrager mit Data_E verschickt. Zusätzlich wird das Cluster-Bit des Anfragers gesetzt (in diesem Fall ist es bereits gesetzt). Zusammen mit der Antwort wird das Bit my_copy gesetzt, und die ursprünglichen Cluster-Bits werden an den SA0 verschickt. Der SA0 erhält die RspFwdI zusammen mit dem gesetzten my_copy. Er überprüft die Cluster-Bits von dem CC1 und entscheidet, ob er den anfragenden Cluster snoopen muss. Ein Snoop wird an den anfragenden Cluster ausgegeben, wobei das Bit snp_all gesetzt ist. Der CC0 wird den Snoop beenden und wird eine RspI/RspS an SA0 senden. Der SA0 sendet ein Cmp an CC0. CC0 kann nun die Daten benutzen, ohne sie in seinen lokalen Cache zu füllen.
Mit Bezug noch auf Tabelle 2 sei RdData/RdInvlOwn lokaler Clusterfehler angenommen, entfernter Cluster M/E, wobei keine lokale Kern-Bits gesetzt sind. Nur das Cluster-Bit des anfragenden Clusters ist gesetzt. Ein weiterer Kern in dem anfragenden Cluster enthält die Zeile im Zustand M. RspFwdI. Der verschickende Kern sendet die Daten direkt an den anfragenden Cluster (seinen eigenen Cluster). Sein lokaler Cluster sendet eine RspFwdI an den SA. In diesem Fall erhält der SA zwei RspFwdI's. Der anfragende Cluster wird die Daten zweimal erhalten, und er muss die Daten von daheim entsorgen. Modifizierte Daten werden an den anfragenden Kern geliefert, wenn die Anfrage vom Typ RdInvlOwn ist. Wenn die ursprüngliche Anfrage ein RdData ist, denn liefert der lokale Cluster die Daten an den anfragenden Kern im Zustand E und leitet einen Strom Wr Miss für die aktuelle Zeile ein. Der CC0 wird eine Fehleranfrage an den SA0 senden, wobei das Bit xnp_only auf 0 gesetzt ist und das Bit rd_miss gesetzt ist. Der SA0 überprüft die Cluster-Bits und sendet einen Snoop an CC1, wobei local_snp gesetzt ist und snp_all auf 0 gesetzt ist. Der CC1 wird einen Treffer in seinem Cache haben, er wird seine lokalen Kern-Bits überprüfen und die geeignete Verarbeitung abschließen. In diesem Fall wird die Zeile in den Zustand S überführt. Dann wird er mit RspFwdI an SA0 antworten. Die Daten werden an den Anfrager mit Data_E verschickt. Zusätzlich wird das Cluster-Bit des Anfragers gesetzt. Zusammen mit der Antwort wird das Bit my_own gesetzt, und die ursprünglichen Cluster-Bits werden an den SA0 geschickt. Der SA0 erhält die RspFwdI zusammen mit dem gesetzten my_own. Er überprüft die Cluster-Bits vom CC1 und entscheidet, ob er den anfragenden Cluster snoopen muss. Ein Snoop wird an den anfragenden Cluster ausgegeben, wobei das Bit snp_all gesetzt ist. Der Snoop wird beendet und eine RspFwdI an SA0 gesendet. Die Daten werden von dem Kern M an die Logik des Kern-Cache-Clusters geschickt. Diese Daten werden die Daten überschreiben, die von dem CC1 zurückgegeben werden. Die Daten sind nun im Zustand M. Der CC0 leitet einen Strom wr_miss ein und gibt die Daten an den Anfrager im Zustand E zurück. Er wird sie nicht in seinen Cache füllen.
Weiter noch mit Bezug auf Tabelle 2 sei RdInvlOwn angenommen, dessen Fassungszustand S ist. Es ist ein Fehler in dem lokalen Cluster und der Zustand des Eigentümer-Cache gibt einen gemeinsam genutzten Zustand an. Grundsätzlich wird die Zeile in der Fassung aufgeräumt und eine externe Anfrage wird verschickt. Der CC0 wird eine Fehleranfrage an den SA0 schicken, wobei das Bit xnp_only auf 0 gesetzt ist und das Bit rd_miss gesetzt ist. Der SA0 überprüft die Cluster-Bits und sendet einen Snoop an CC1, wobei local_snp gesetzt ist und snp_all auf 0 gesetzt ist. Der CC1 wird einen Treffer in seinem Cache haben, er wird seine lokalen Kern-Bits überprüfen und geeignete Verarbeitung abschließen. Er wird mit RspI an den SA0 antworten und seine lokale Kopie ungültig machen. Zusammen mit der Antwort wird das Bit my_own gesetzt und die ursprünglichen Cluster-Bits werden an SA0 verschickt. Der SA0 empfängt die RspI zusammen mit dem gesetzten my_own. Er überprüft die Cluster-Bits von dem CC1 und entscheidet, ob er den anfragenden Cluster snoopen muss. Ein Snoop wird an den anfragenden Cluster ausgegeben, wobei das Bit snp_all gesetzt ist. Der CC0 wird den Snoop abschließen und wird eine RspI an den SA0 senden. Der SA0 sendet dann eine Quellenrundsendung; auf CSI mit RdInvlOwn. Schließlich wird die System-Kopplungsstruktur ein DataC_E_Cmp an den CC0 senden. Diese Zeile wird in den Cache CC0 geführt und an den anfragenden Kern geliefert.
Mit Bezug weiter auf die Tabelle 2 sei ein Write-back-Vorgang von einem Kern angenommen, der den lokalen Cache verfehlt. Der SA wird zunächst einen Snoop „keine Arbeit” (nop – no Operation) senden. Dieser Snoop wird keinerlei Effekt auf den Zustand des Cache haben. Basierend auf den Antworten kann der SA bestimmen, welcher Cluster der Eigentümer-Cluster ist. Der CC0 wird eine Schreibfehleranfrage an den SA0 senden, wobei das Bit rd_miss auf 1 gesetzt ist, und der SA0 sendet Cluster-Bits und sendet einen nop-snoop an den CC1, wobei local_snp gesetzt ist und snp_all auf 0 gesetzt ist. Der CC1 wird einen Treffer in seinem Cache haben. Da es ein Treffer ist, jedoch ein nop ist, werden keine Änderungen an dem Zustand des Cache vorgenommen. Jedoch wird eine RspI verschickt, wobei das Bit my_own gesetzt ist. Der SA0 wird nun einen Snoop data_pull an den anfragenden Cluster mit der Identifikation des Eigentümer-Clusters senden. Der CC0 wird dann ein Rückschreiben an den Eigentümer-Cluster schicken. Beim Empfang eines Abschlusses von dem Eigentümer-Cluster wird er eine die Zuweisung nichtig machende Nachricht an den SA senden.
Mit Bezug noch auf die Tabelle 2 kann eine Räumung eines Cluster-Cache geschehen. Da Räumungen nur bei einem Eigentümer-Cache geschehen können, werden die Cluster-Bits an SA geschickt. Der SA führt ein geeignetes Aufräumen bei anderen Cluster-Caches durch, und die Räumung wird dann an den Systemspeicher hinausgeschickt. Der CC0 wird eine Schreibanfrage an den SA0 schicken, wobei das Bit rd_miss auf 0 gesetzt ist und die Clusters-Bits angegeben sind. Der SA0 sendet Snoops an alle Cluster, für die die Cluster-Bits angegeben sind. Local_snp ist gesetzt und snp_all ist gesetzt. Der CC1 antwortet auf den Snoop mit einer RspI, und das Bit my_own wird rückgesetzt. Sobald alle Antworten empfangen sind, wird data_pull dem anfragenden Cluster angezeigt. Der anfragende Cluster kann nun das WbMtoI direkt an das externe System senden. Schließlich wird die Transaktion in der CSI-Domäne abgeschlossen und das Aufheben der Zuweisung wird an den SA geschickt.
Mit Bezug noch auf die Tabelle 2 enden hereinkommende Snoop-Transaktionen durch das Ausführen der beiden Snoop-Schritte. Als erstes wird der Anfrage-Snoop ausgeführt, dann wird der Aufräum-Snoop ausgeführt. Reinkommende Snoops werden in den SA0 gewiesen. Der SA0 sendet Snoops an alle Cluster, wobei local_snp auf 0 gesetzt ist und snp_all auf 0 gesetzt ist. Der Eigentümer-Cluster wird mit einem RspFwdI antworten und das Bit my_own wird gesetzt. In diesem Fall ist es CC0. CC1 sendet eine RspI. Der SA0 sendet eine kombinierte RspFwdI nach Hause für die hereinkommenden Snoops. Er sendet dann eine Datenzieh-Nachricht an CC0 (Eigentümer-Cluster). Der CC0 sendet beim Empfang der Datenziehnachricht die Datennachricht an den Anfrager des ursprünglichen Snoop.
Ausführungsformen können für CMP-Plattformen geeignet sein, um den Verkehr zwischen den CMPs zu verringern. Wie es in der 5 gezeigt ist, ist das Multiprozessorsystem 500 ein Punkt-zu-Punkt-Kopplungsstruktursystem und umfasst einen ersten Prozessor 570 und einen zweiten Prozessor 580, die über eine Punkt-zu-Punkt-Kopplungsstruktur 550 gekoppelt sind, obwohl das System eine andere Busarchitektur nutzen kann. Wie es in der 5 gezeigt ist, kann jeder der Prozessoren 570 und 578 ein Mehrkern-Prozessor sein, der einen ers ten und einen zweiten Prozessorkern umfasst (d. h. die Prozessorkerne 574a und 574b und die Prozessorkerne 584a und 584b), obwohl weitere Kerne vorhanden sein können. Weiterhin, wie es in der 5 gezeigt ist, können ein SA 575 und 585, die eine Vereinigung einzelner SAs für jeden Prozessor sein können, an jedes Paar der Prozessorkerne 574a und 574b beziehungsweise 584a und 584b gekoppelt sein, um den Speicherverkehr gemäß einer Ausführungsform der vorliegenden Erfindung zu behandeln. Noch mit Bezug auf 5 umfasst ein erster Prozessor 570 weiter einen Speichercontroller-Hub (MCH) 572 und Punkt-zu-Punkt(P-P)-Schnittstellen 576 und 578. Ähnlich umfasst der zweite Prozessor 580 einen MCH 582 und P-P-Schnittstellen 586 und 588. Wie es in der 5 gezeigt ist, koppeln die MCHs 572 und 582 die Prozessoren mit jeweiligen Speichern, nämlich einem Speicher 532 und einem Speicher 534, die Teile eines Hauptspeichers (z. B. eines dynamischen Speichers mit wahlfreiem Zugriff (DRAM)) sein können.
Der erste Prozessor 570 und der zweite Prozessor 580 können mittels P-P-Kopplungsstrukturen 552 bzw. 554 an einen Chipsatz 590 gekoppelt sein. Wie es in der 5 gezeigt ist, umfasst der Chipsatz 590 P-P-Schnittstellen 594 und 598. Weiterhin umfasst der Chipsatz 490 eine Schnittstelle 592, um den Chipsatz 590 mit einer hoch leistungsfähigen Grafikmaschine 538 zu koppeln. Bei einer Ausführungsform kann ein Advanced Graphics Port(AGP)-Bus 539 oder eine Punkt-zu-Punkt-Kopplungsstruktur verwendet werden, um die Grafikmaschine 538 mit dem Chipsatz 590 zu koppeln. Wie es in der 5 gezeigt ist, können verschiedene I/O-Einheiten 514 an den ersten Bus 516 gekoppelt werden, zusammen mit einer Bus-Brücke 518, die den ersten Bus 516 mit einem zweiten Bus 520 koppelt. Verschiedene Einheiten können an den zweiten Bus 520 gekoppelt werden, einschließlich zum Beispiel einer Tastatur/Maus 522, Kommunikationseinheiten 526 und einer Datenspeichereinheit 528, die bei einer Ausführungsform Code 530 umfassen kann. Weiter kann eine Audio-I/O 524 an den zweiten Bus 520 gekoppelt sein.
Obwohl die vorliegende Erfindung mit Bezug auf eine beschränkte Anzahl an Ausführungsformen beschrieben worden ist, werden die Fachleute zahlreiche Modifikationen und Abänderungen erkennen. Es ist beabsichtigt, dass die angefügten Ansprüche alle solchen Modifikationen und Abänderungen abdecken, wie sie in den wahren Gedanken und Umfang dieser Erfindung fallen.
ZUSAMMENFASSUNG
Bei einer Ausführungsform umfasst die vorliegende Erfindung ein Verfahren zum Empfangen angeforderter Daten von einer System-Kopplungsstrukturschnittstelle in einem ersten Agenten für die Skalierbarkeit eines Mehrkernprozessors, der eine Vielzahl von Kern-Cache-Clustern umfasst, zum Speichern der angeforderten Daten in einer Zeile eines lokalen Cache eines ersten Kern-Cache-Clusters, der einen anfragenden Kern umfasst, und zum Aktualisieren eines Clusterfeldes und eines Kernfeldes in einem Vektor eines Tag-Array für die Zeile. Weitere Ausführungsformen sind beschrieben und beansprucht.

Claims

Verfahren, das aufweist: Empfangen angeforderter Daten von einer Systemkopplungsstruktur-Schnittstelle in einem ersten Skalierbarkeitsagenten (SA – Scalability Agent) eines Mehrkernprozessors, der eine Vielzahl von Kern-Cache-Clustern umfasst; Speichern der angeforderten Daten in einer Zeile eines lokalen Cache eines ersten Kern-Cache-Clusters, der einen anfragenden Kern umfasst; und Aktualisieren eines Cluster-Feldes und eines Kern-Feldes in einem Vektor eines Tag-Array für die Zeile.
Verfahren nach Anspruch 1, das weiter das Bereitstellen der angeforderten Daten für den anfragenden Kern umfasst.
Verfahren nach Anspruch 2, das weiter das Halten der angeforderten Daten nur in der Zeile des lokalen Cache umfasst.
Verfahren nach Anspruch 1, das weiter das Empfangen, in dem ersten Skalierbaragenten, einer Anfrage von einem zweiten Kern-Cache-Cluster nach den angeforderten Daten mit einem Cross-Snoop-Indikator, der einen ersten Zustand hat, umfasst.
Verfahren nach Anspruch 4, das weiter das Bereitstellen der angeforderten Daten an den anfragenden Kern des zweiten Kern-Cache-Clusters in einer Erwiderungstransaktion und das Nicht-Speichern der angeforderten Daten in einem lokalen Cache des zweiten Kern-Cache-Clusters, wenn ein lokaler Datenindikator, der mit der Erwiderungstransaktion verknüpft ist, einen ersten Zustand hat, umfasst.
Verfahren nach Anspruch 4, das weiter das Bereitstellen der angeforderten Daten an den anfragenden Kern des zweiten Kern-Cache-Clusters in einer Erwiderungstransaktion und das Speichern der angeforderten Daten in einem lokalen Cache des zweiten Kern-Cache-Clusters, wenn ein lokaler Datenindikator, der mit der Erwiderungstransaktion verknüpft ist, einen zweiten Zustand hat, umfasst.
Verfahren nach Anspruch 1, das weiter das Bereitstellen der angeforderten Daten aus der Zeile des ersten Kern-Cache-Clusters direkt von dem lokalen Cache als Antwort auf eine Leseanfrage, ohne dass der erste SA zugreift, umfasst, wenn der Vektor angibt, dass irgendein Kern aus dem ersten Kern-Cache-Cluster auf die angeforderten Daten zugegriffen hat.
Verfahren nach Anspruch 1, bei dem das Aktualisieren des Cluster-Feldes und des Kern-Feldes das Setzen eines Cluster-Bits und eines Kern-Bits, die mit dem ersten Kern-Cache-Cluster und dem Anfragerkern in dem Vektor verknüpft sind, umfasst.
Vorrichtung, die aufweist: eine Vielzahl von Kern-Cache-Clustern, die jeder einen Cache-Speicher und einen oder mehrere Prozessorkerne in Kommunikation mit dem Cache-Speicher umfassen, wobei der Cache-Speicher jedes Kern-Cache-Clusters nicht inklusiv ist und die Vereinigung der Cache-Speicher aller Kern-Cache-Cluster inklusiv ist; eine Vielzahl von Skalierbarkeitsagenten, die jeder mit einem aus der Vielzahl der Kern-Cache-Cluster gekoppelt ist, wobei der Skalierbarkeitsagent dazu dient, entsprechend einem Protokoll sicherzustellen, dass die Vielzahl der Kern-Cache-Cluster als ein einziger Cache-Agent erscheint; und eine Kopplungsstruktur, die mit der Vielzahl der Skalierbarkeitsagenten gekoppelt ist.
Vorrichtung nach Anspruch 1, bei der die Vereinigung der Cache-Speicher zusammen einen gemeinsam genutzten Cache-Speicher bildet.
Vorrichtung nach Anspruch 9, bei der nur eine einzige Kopie von Daten in der Vereinigung der Cache-Speicher vorhanden sein soll.
Vorrichtung nach Anspruch 9, bei der die Vielzahl der Skalierbarkeitsagenten einen ersten Ladezugriff auf Daten zu dem Cache-Speicher des Kern-Cache-Clusters, der die Daten angefordert hat, zur Verfügung stellt.
Vorrichtung nach Anspruch 9, bei der der Cache-Speicher einen Tag-Array umfasst, um Vektoren zu steuern, wobei jeder Vektor ein erstes Feld, um ein Cluster-Bit für jeden Kern-Cache-Cluster zu speichern, um anzugeben, welcher Kern-Cache-Cluster eine entsprechende Cache-Zeile enthält, und ein zweites Feld, um ein Kern-Bit für jeden Kern des entsprechenden Kern-Cache-Clusters zu speichern, umfasst.
Vorrichtung nach Anspruch 13, bei der jeder Kern-Cache-Cluster eine Cluster-Zahl hat, die mit ihm verknüpft ist.
System, das aufweist: einen ersten Prozessor, der eine erste Vielzahl von Kern-Cache-Clustern umfasst, von denen jeder einen ersten Cache-Speicher, erste Prozessorkerne in Kommunikation mit dem ersten Cache-Speicher und einen ersten Skalierbarkeitsagenten (SA) umfasst, wobei der erste Cache-Speicher jedes Kern-Cache-Clusters nicht inklusiv ist und die Vereinigung der ersten Cache-Speicher alle aus der Vielzahl der Kern-Cache-Cluster inklusiv ist; einen zweiten Prozessor, der eine zweite Vielzahl von Kern-Cache-Clustern umfasst, von denen jeder einen zweiten Cache-Speicher, zweite Prozessorkerne in Kombination mit dem zweiten Cache-Speicher und einen zweiten SA umfasst, wobei der zweite Cache-Speicher jedes Kern-Cache-Clusters nicht inklusiv ist und die Vereinigung der zweiten Cache-Speicher von allen aus der zweiten Vielzahl der Kern-Cache-Cluster inklusiv ist; eine Punkt-zu-Punkt(PTP)-Kopplungsstruktur, um den ersten Prozessor und den zweiten Prozessor zu koppeln; und einen dynamischen Speicher mit wahlfreiem Zugriff (DRAM – Dynamic Random Access Memory), der mit dem ersten Prozessor gekoppelt ist.
System nach Anspruch 15, bei dem der erste SA die Daten nur in einer Zeile eines entsprechenden ersten Cache-Speichers nach einer Anforderung der Daten von einem unterschiedlichen aus der ersten Vielzahl der Kern-Cache-Cluster hält.
System nach Anspruch 15, bei dem die Vereinigung der ersten Cache-Speicher zusammen einem gemeinsam genutzten Cache-Speicher für den ersten Prozessor bildet.
System nach Anspruch 15, bei dem der erste Cache-Speicher einen Tag-Array umfasst, um Vektoren zu speichern, von denen jeder ein erstes Feld umfasst, um ein Cluster-Bit für jeden aus der Vielzahl der Kern-Cache-Cluster zu speichern, um anzugeben, welcher aus der Vielzahl der Kern-Cache-Cluster eine entsprechende Cache-Zeile umfasst, und ein zweites Feld, um ein Kern-Bit für jeden Kern aus dem entsprechenden aus der ersten Vielzahl der Kern-Cache-Cluster zu speichern, umfasst.
System nach Anspruch 18, bei dem aus der Vielzahl der Kern-Cache-Cluster eine Cluster-Zahl hat, die mit ihm verknüpft ist, die in dem Cluster-Bit des Tag-Array zu speichern ist.