DE112018002032T5

DE112018002032T5 - Gemeinsames nutzen von virtuellen und realen übersetzungen in einem virtuellen cache

Info

Publication number: DE112018002032T5
Application number: DE112018002032.0T
Authority: DE
Inventors: Martin Recktenwald; Christian Jacobi; Johannes Christian Reichart; Markus Michael Helms
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 2017-06-16
Filing date: 2018-06-14
Publication date: 2020-01-16
Also published as: US20180365164A1; WO2018229700A1; US10810134B2; US20180365161A1; GB2577468B; GB2577468A; GB202000448D0; JP7062696B2; US10606762B2; JP2020523682A

Abstract

Hierin offenbart ist ein virtuelles Cacheverzeichnis in einem Prozessor, der Adressübersetzungen beseitigt, wenn die virtuelle Adresse und die reale Adresse in dem Cacheverzeichnis dieselben sind. Der Prozessor ist konfiguriert, virtuellen Speicher und mehrere Threads zu unterstützen. Das virtuelle Cacheverzeichnis enthält eine Mehrzahl von Verzeichniseinträgen, jeder Eintrag ist einer Cachezeile zugeordnet. Jede Cachezeile besitzt ein Tag. Das Tag enthält eine logische Adresse, eine Adressraumkennung, einen Bitanzeiger einer realen Adresse und einen Anzeiger von virtueller Adresse zu realer Adresse. Dieser Anzeiger von virtueller Adresse zu realer Adresse zeigt an, ob die logische Adresse und die reale Adresse dieselben sind. Bei Aktivierung wird keine Adressübersetzung durchgeführt.

Description

HINTERGRUND
Die vorliegende Offenbarung bezieht sich auf das Gebiet von digitalen Computersystemen und insbesondere auf ein Verfahren zum Steuern eines Zugriffs auf einen Cachespeicher.
Jüngste Mikroprozessorarchitektur erlaubt es Software, sogenannte „virtuelle“ (oder manchmal „logisch“ genannte) Adressen zu verwenden, um Speicherorte zu referenzieren. Der Speicherzugriff selbst erfolgt unter Verwendung einer „physischen“ (oder manchmal „absolut“ genannten) Adresse. Um zwischen den zweien zu übersetzen wird üblicherweise eine Datenstruktur einbezogen, die „Translation Lookaside Buffer“ (TLB) genannt wird. Der Prozess des Übersetzens wird manchmal dynamische Adressübersetzung (Dynamic Address Translation (DAT)) genannt, insbesondere in der IBM z/Architecture.
In einem üblichen Mikroprozessorsystem werden mehrere Ebenen von Caches verwendet, um Speicherzugriffe zu beschleunigen, indem eine Kopie der Speicherinhalte „nahe“ am Prozessorkern beibehalten wird. Bei Cacheimplementierungen, die DAT unterstützen, indexiert eine häufig verwendete Implementierung in das Cacheverzeichnis unter Verwendung eines Teils der logischen Adresse, und die sogenannten „Tag“-Informationen, mit der die Nachschlageanforderung verglichen wird, verwendet absolute Adressen. Dies erfordert eine Übersetzung der logischen Adresse, wie sie durch das Programm verwendet wird, in eine absolute Adresse, üblicherweise unter Einbeziehen eines Nachschlagens in dem TLB.
Mit ständig wachsenden Mikroprozessorkerncaches müssen TLBs jedoch ebenfalls wachsen, und die Leistungsaufnahme des TLB-Nachschlagens zusätzlich zum Verzeichnisnachschlagen trägt signifikant zur Mikroprozessorkernleistung bei. Zudem ist die Größe des TLB durch Zeiteinschränkungen begrenzt, da das TLB-Nachschlagen selbst Teil des kritischen Pfades wird.
KURZDARSTELLUNG
Vielfältige Ausführungsformen stellen ein Verfahren zum Steuern eines Zugriffs auf einen Cachespeicher, eine Vorrichtung und ein Computerprogrammprodukt bereit, wie durch den Gegenstand der unabhängigen Ansprüche beschrieben. Vorteilhafte Ausführungsformen werden in den abhängigen Ansprüchen beschrieben. Ausführungsformen der vorliegenden Erfindung können frei miteinander kombiniert werden, wenn sie sich nicht gegenseitig ausschließen.
Eine bestimmte Ausführungsform ist auf ein virtuelles Cacheverzeichnis in einem Prozessor gerichtet. Der Prozessor ist konfiguriert, virtuellen Speicher und mehrere Threads zu unterstützen. Das virtuelle Cacheverzeichnis enthält eine Mehrzahl von Verzeichniseinträgen, jeder Eintrag ist einer Cachezeile zugeordnet. Jede Cachezeile besitzt ein Tag. Das Tag enthält eine logische Adresse, eine Adressraumkennung, einen Bitanzeiger einer realen Adresse und einen Anzeiger von virtueller Adresse zu realer Adresse.
Eine bestimmte Ausführungsform ist auf ein Verfahren zum Betreiben eines primären Prozessorcaches für einen Prozessor mit Unterstützung von virtuellem Speicher gerichtet. Der Prozessor verwendet ein logisch indexiertes und logisch getagtes Cacheverzeichnis, und ein Eintrag in dem Verzeichnis enthält eine absolute Speicheradresse zusätzlich zu einer entsprechenden logischen Speicheradresse und ein Flag von virtuell zu real, das angibt, dass die logische Adresse dieselbe wie die reale Adresse ist. Das Verfahren speichert Code in eine logische Speicheradresse in einem ersten Eintrag in dem Cacheverzeichnis. Sobald der Code gespeichert ist, ruft ein Benutzercode ein zugrundeliegendes Betriebssystem auf. Das Betriebssystem liest den Code aus der absoluten Speicheradresse. Sobald der Code aus der absoluten Speicheradresse gelesen ist, wird ein Transload an dem ersten Eintrag ausgeführt. Auf den Transload folgend ermittelt das Verfahren, ob die absolute Speicheradresse gleich der logischen Speicheradresse ist. Falls die absolute Speicheradresse gleich der logischen Speicheradresse ist, wird das Flag von virtuell zu real auf Ein gesetzt, was anzeigt, dass die absolute und logische Adresse dieselbe sind.
Figurenliste
Im Folgenden werden Ausführungsformen der Erfindung in lediglich beispielhafter Weise detaillierter erklärt, wobei Bezug auf die Zeichnungen genommen wird, in denen:

1 ein Computersystem gemäß einem Beispiel der vorliegenden Offenbarung veranschaulicht;
2 ein Blockschaubild ist, das ein Schaubild zum Zugreifen auf eine Cachestruktur eines Cachespeichers mit Zweiebenencache veranschaulicht;
3 ein Ablaufplan eines Verfahrens zum Betreiben des Cachespeichers von 2 ist;
4 ein Ablaufplan eines Verfahrens zum Auflösen von Synonymen im Cachespeicher von 2 ist.
5 ein Ablaufplan eines Verfahrens zum Steuern eines Zugriffs auf einen Cachespeicher ist;
6 eine Schaubildveranschaulichung eines Tags gemäß Ausführungsformen ist;
7 ein Ablaufplan ist, der einen Prozess eines Datentransfers durch gemeinsam genutzten Speicher veranschaulicht;
8 ein Ablaufplan ist, der die Erweiterung von virtuell zu real in den Cache gemäß Ausführungsformen veranschaulicht;
9 eine Schaubildveranschaulichung eines Verzeichnisvergleichens unter Verwendung der Erweiterung gemäß Ausführungsformen ist;
10 eine Schaubildveranschaulichung eines Tags gemäß Ausführungsformen ist;
11 ein Ablaufplan ist, der einen Prozess zum Zugreifen auf eine Cachezeile durch einen ersten Thread gemäß Ausführungsformen veranschaulicht;
12 ein Ablaufplan ist, der einen Prozess zum Zugreifen auf eine gemeinsam genutzte Cachezeile durch einen zweiten Thread gemäß Ausführungsformen veranschaulicht;
13 ein Entscheidungsbaum ist, der den Prozess von 11 und 12 kombiniert gemäß Ausführungsformen veranschaulicht;
14 ein Ablaufplan ist, der das Auflösen eines L1-Cachefehlers gemäß Ausführungsformen veranschaulicht;
15 eine Schaubildveranschaulichung eines gemeinsamen Nutzens von Cache für Threads ist, die unterschiedliche Übersetzungen verwenden;
16 eine Schaubildveranschaulichung eines gemeinsamen Nutzens von Abschnitten eines Verzeichniseintrags gemäß Ausführungsformen ist;
17 ein Entscheidungsbaum ist, der den Prozess eines teilweisen gemeinsamen Threadnutzens von Verzeichniseinträgen gemäß Ausführungsformen realisiert.

DETAILLIERTE BESCHREIBUNG
Die Beschreibungen der verschiedenen Ausführungsformen der vorliegenden Erfindung werden zu Zwecken der Veranschaulichung vorgelegt, sind jedoch nicht als erschöpfend oder auf die offenbarten Ausführungsformen begrenzt gedacht. Viele Änderungen und Variationen sind für den Fachmann ersichtlich, ohne vom Umfang und Geist der beschriebenen Ausführungsformen abzuweichen. Die hierin verwendete Terminologie wurde gewählt, um die Grundgedanken der Ausführungsformen, die praktische Anwendung oder technische Verbesserung gegenüber auf dem Markt anzutreffenden Technologien am besten zu erklären oder um es anderen Fachleuten zu ermöglichen, zu verstehen.
Bei dem Cachespeicher handelt es sich um einen satzassoziativen Cache.
Das vorliegende Verfahren verwendet ein logisch indexiertes, logisch getagtes Verzeichnis, das alle übersetzungsrelevanten Informationen im L1-Cache speichert Um so viel Leistung wie möglich einzusparen, verwendet das vorliegende Verfahren ein Satzverzeichnis, um die potenzielle Treffereinstellung für die anderen L1-Cachestrukturen auszuwählen. Das Satzverzeichnis wird als Cachearray-Spätauswahl verwendet und trägt somit verglichen mit einer herkömmlichen Gestaltung möglicherweise nichts zum Leistungs- und Flächenbudget bei. Beim Verwenden des Satzverzeichnisses zum Einsparen zusätzlicher Leistung wird ein „vertikal gestapeltes“ Verzeichnis (d.h. das Validierungsverzeichnis) anstatt einer herkömmlichen satzassoziativen Verzeichnisstruktur verwendet. Als ein Ergebnis kann immer nur ein einziger Satz ausgelesen werden, während im Stand der Technik alle zu einem gegebenen Index gehörenden Sätze parallel gelesen werden konnten Da zum Beispiel das Cacheverzeichnis verwendet werden kann, um Synonymprobleme aufzulösen, muss möglicherweise nicht auf die Validierungsverzeichnissätze parallel zugegriffen werden.
Das vorliegende Verfahren kann den Vorteil eines Bereitstellens eines verbesserten satzassoziativen Cachespeichers mit kurzer Zugriffszeit und doch geringer Leistungsaufnahme verglichen mit Verfahren des Stands der Technik besitzen, wo ein L1-Cachetreffer eine Validierung von einem übergeordneten Cache erfordert.
Aufgrund seiner relativ großen Größe kann der TLB gewöhnlicherweise nicht in großer Nähe zum Speicherarray platziert werden. Als ein Ergebnis steigt die Gesamtspeicherzugriffszeit eines satzassoziativen Cachespeichers mit den Größen seines TLB und seiner Speicherarrays. Das vorliegende Verfahren verwendet ein logisch getagtes und logisch indexiertes Validierungsverzeichnis und kann somit das Erfordernis vermeiden, einen TLB für eine L1-Cachetreffer-Signalerzeugung mit Strom zu versorgen.
Falls gemäß einer bestimmten Ausführungsform das zweite Suchen die Anwesenheit der Cachezeile im Satz nicht bestätigt, Erzeugen eines Fehlersignals. Das Fehlersignal ist ein Cachefehlersignal, das einen Cachefehler für die angeforderte effektive Adresse (auch als logische oder virtuelle Adresse bezeichnet) anzeigt. Das Cachefehlersignal kann auch erzeugt werden, wenn das erste Suchen, um die angeforderte logische Adresse im Satzverzeichnis zu finden, fehlschlägt. Als Reaktion auf das erzeugte Fehlersignal kann die angeforderte Cachezeile in einer höheren Cacheebene oder im Hauptspeicher (z.B. RAM) gesucht werden.
Gemäß einer bestimmten Ausführungsform weist der Cachespeicher ferner einen Translation Lookaside Buffer, TLB, auf, wobei ein gegebener Eintrag im primären Cacheverzeichnis ein gültiges Bit, einen Abschnitt der effektiven Adresse und einen Satzindex speichert, wobei im Falle, dass das zweite Suchen die Anwesenheit der Cachezeile im Satz nicht bestätigt, das Verfahren ferner aufweist: Suchen der Zeilenindexbits im primären Cachespeicher, was zu einem logischen Zeiger für jeden Satz im primären Cacheverzeichnis führt, wobei der logische Zeiger den Satzindex und den Abschnitt der effektiven Adresse aufweist; Auswählen eines logischen Zeigers der logischen Zeiger, dessen Satzindex mit der Satzkennung übereinstimmt; Suchen der effektiven Adresse im TLB zum Identifizieren einer absoluten Adresse, die der effektiven Adresse zugeordnet ist; Suchen der effektiven Adresse in einem übergeordneten sekundären Cacheverzeichnis des Cachespeichers zum Erlangen eines Eintrags, welcher der effektiven Adresse in jedem Satz im sekundären Cacheverzeichnis entspricht, wobei der Eintrag eine andere absolute Adresse aufweist; Vergleichen jeder erlangten absoluten Adresse des sekundären Cacheverzeichnisses mit der absoluten Adresse des TLB, was zu einer weiteren Satzkennung eines Satzes des sekundären Cacheverzeichnisses führt; Vergleichen der logischen Adresse des Eintrags des Satzes des sekundären Cacheverzeichnisses, das die andere Satzkennung besitzt, mit dem ausgewählten logischen Zeiger, und auf Grundlage der Vergleichsergebnisse ein Bestätigen des Fehlersignals oder Aktualisieren der Satz- und Validierungsverzeichnisse.
Der TLB und der übergeordnete Cache werden zum Beispiel im Falle eines Cachefehlers im untergeordneten Cache verwendet. Dies kann eine zuverlässige Validierung oder Bestätigung des Cachefehlers bei der unteren Cacheebene bereitstellen.
Gemäß einer bestimmten Ausführungsform wird das Durchsuchen des primären Cachespeichers parallel zum ersten Suchen durchgeführt. Diese Ausführungsform kann den Zugriff auf Daten weiter beschleunigen.
Gemäß einer bestimmten Ausführungsform weist das Verfahren ferner auf: das Erzeugen des Treffersignals wird durchgeführt, wenn das gültige Bit des logischen Zeigers auf einen gültigen Zustand gesetzt wird. Das gültige Bit ist ein Informationsbit, das angibt, ob die Daten in einer Cachezeile gültig sind. Dies kann weiter Verarbeitungszeit einsparen, die andernfalls für das Zugreifen auf für ungültig erklärte Daten und Verarbeiten induzierter Korrekturen erforderlich wäre.
Gemäß einer bestimmten Ausführungsform wird die Suche im TLB und die Suche im sekundären Cacheverzeichnis parallel durchgeführt. Diese Ausführungsform kann den Zugriff auf Daten weiter beschleunigen.
Gemäß einer bestimmten Ausführungsform sind die erste Gruppe von Bits die niedrigwertigsten Bits aus dem Tagfeld, und die zweite Gruppe von Bits sind die höchstwertigsten Bits aus dem Tagfeld. Die zweite Gruppe von Bits kann komplementär zur ersten Gruppe von Bits zum Bestätigen des Suchergebnisses des Satzverzeichnisses sein. Wenn zum Beispiel die effektive Adresse ein gespeichertes Tag von 0:49 Bits besitzt, kann die erste Gruppe von Bits 37:49 sein und die zweite Gruppe von Bits kann 0:36 sein. Jeder Teilsatz des gespeicherten Tags 0:49 kann jedoch als die erste oder zweite Gruppe von Bits verwendet werden. Die Breite der ersten Gruppen von Bits (d.h. Anzahl von Bits) kann auf einem Ausgleich zwischen Einschränkungen falscher Vorhersagen (nicht zu klein) und Zeiteinschränkungen (keine zu breiten Vergleiche) beruhen. Ein Verwenden der Bits neben dem Zeilenindex (50:55) der effektiven Adresse für die erste Gruppe kann vorteilhaft sein, weil dies auch für Programme mit kleinem Speicherplatzbedarf funktioniert. Wenn zum Beispiel die Bits 0:12 für die erste Gruppe verwendet werden, sind die meisten Programme möglicherweise nicht in der Lage, die n-fache (z.B. n = 8) Assoziativität zu verwenden, weil nur große Programme effektive Adressen besitzen können, die sich in 0:12 unterscheiden, so dass normal große Programme nur einen Satz verwenden könnten. In anderen Worten werden die Bits der ersten Gruppe (z.B. 37:49) so gewählt, dass sie sich für die meisten Speicherzugriffe unterscheiden und sich noch nicht mit dem Zeilenindex überlappen.
Gemäß einer bestimmten Ausführungsform wird das Validierungsverzeichnis aus einer physischen Arraystruktur aufgebaut, die einen Verzeichniseintrag pro Cachezeile von allen Sätzen des Cachespeichers speichert. Diese Ausführungsform kann es ermöglichen, dass nur ein einziger Satz gleichzeitig ausgelesen werden kann, während im Stand der Technik alle zu einem gegebenen Index gehörenden Sätze parallel gelesen werden konnten. Diese Ausführungsform kann somit den Zugriff auf Daten weiter beschleunigen. Zum Beispiel kann das Ergebnis des Satzverzeichnisses (z.B. eine Satzkennung) als Erweiterung zum Zeilenindex (z.B. Bits 50:55) zum Durchsuchen des Validierungsverzeichnisses verwendet werden.
Gemäß einer bestimmten Ausführungsform speichert ein gegebener Eintrag im primären Cacheverzeichnis ein gültiges Bit, einen Abschnitt der effektiven Adresse und einen Satzindex, wobei das Verfahren ferner aufweist: parallel zum ersten Suchen ein Durchsuchen der Zeilenindexbits im primären Cacheverzeichnis, was zu einem gültigen Bitwert für jeden Satz im primären Cacheverzeichnis führt, ein Auswählen eines gültigen Bitwerts der gültigen Bitwerte, deren zugeordneter Satzindex mit der Satzkennung übereinstimmt, wobei das Erzeugen des Treffersignals durchgeführt wird, wenn der gültige Bitwert einen gültigen Zustand angibt. Dies kann weiter Verarbeitungszeit einsparen, die andernfalls für das Zugreifen auf für ungültig erklärte Daten und Verarbeiten induzierter Korrekturen erforderlich wäre.
Gemäß einer bestimmten Ausführungsform ist das primäre Cacheverzeichnis ein L1-Ebenen-Cacheverzeichnis. Gemäß einer bestimmten Ausführungsform ist das sekundäre Cacheverzeichnis ein L2-Ebenen-Cacheverzeichnis. Diese Ausführungsformen können nahtlos in bestehende Systeme integriert werden.
Gemäß einer bestimmten Ausführungsform ist der Cachespeicher ein Mehrfachebenen-Cacheverzeichnis, das ferner ein sekundäres Cacheverzeichnis aufweist. Der Cachespeicher ist ein satzselektiver Speicher.
Gemäß einer bestimmten Ausführungsform speichert ein gegebener Eintrag im primären Cacheverzeichnis ein gültiges Bit, einen Abschnitt der effektiven Adresse und einen Satzindex. Das Verfahren weist ferner auf: ein Empfangen eines zweiten effektiven Adresssynonyms der effektiven Adresse; ein Wiederholen des ersten und zweiten Suchens unter Verwendung der zweiten effektiven Adresse; falls das zweite Suchen das Vorhandensein der durch die zweite effektive Adresse angegebenen Cachezeile nicht bestätigt, ein Erklären des Eintrags des Satzverzeichnisses, welcher der zweiten effektivem Adresse entspricht, für ungültig; ein Durchführen des ersten Suchens unter Verwenden der zweiten effektivem Adresse zum Erfassen eines Fehlers; ein Suchen der zweiten effektiven Adresse im primären Cacheverzeichnis, was zu einem logischen Zeiger für jeden Satz im primären Cacheverzeichnis führt, wobei der logische Zeiger den Satzindex und den Abschnitt der zweiten effektiven Adresse aufweist; ein Suchen der zweiten effektiven Adresse in einem übergeordneten sekundären Verzeichniscache des Cachespeichers zum Erlangen eines Eintrags, welcher der zweiten effektiven Adresse in jedem Satz im sekundären Cacheverzeichnis entspricht; ein Vergleichen der logischen Adresse des Eintrags des Satzes des sekundären Cacheverzeichnisses mit jedem der logischen Zeiger, und auf Grundlage der Vergleichsergebnisse ein Bestätigen des Vorhandenseins der Cachezeile im primären Cacheverzeichnis; ein Aktualisieren der Satz- und Validierungsverzeichnisse durch Überschreiben von Einträgen bezüglich der effektiven Adresse durch die zweite effektive Adresse; ein Wiederholen des ersten Suchens, des zweiten Suchens und der Erzeugung des bedingten Treffersignals. Diese Ausführungsform kann den Vorteil besitzen, Synonymprobleme beim Cachespeicher wirksam zu lösen. Sie löst Synonymprobleme, indem sie auf dem oder den Caches der nächsten Ebene beruht. Sie verwendet das L1-Cacheverzeichnis, um den L1-Cache und den L2-Cache miteinander zu verbinden.
1 veranschaulicht ein Computersystem 100 gemäß einem Beispiel der vorliegenden Offenbarung. Das Computersystem 100 kann auf der durch International Business Machines (IBM) angebotenen z/ Architecture beruhen. Das Computersystem 100 kann eine satzassoziative Cachespeicherstruktur verwenden. Das Computersystem 100 weist mindestens eine Verarbeitungseinheit 101 auf. Die Verarbeitungseinheit 101 kann mit verschiedenen Peripherieeinheiten verbunden sein, einschließlich Eingabe/Ausgabe(E/A)-Einheiten 104 (wie beispielsweise einen Anzeigemonitor, eine Tastatur und eine Permanentdatenspeichereinheit), einer Speichereinheit 106 (wie beispielsweise ein Speicher mit wahlfreiem Zugriff (random-access memory (RAM)), der durch die Verarbeitungseinheiten verwendet wird, um Programmanweisungen auszuführen, und Firmware 108, deren primärer Zweck es ist, ein Betriebssystem von einer der Peripherieeinheiten auszusuchen und zu laden, wann immer der Computer zuerst eingeschaltet wird. Die Verarbeitungseinheit 101 tauscht mit den Peripherieeinheiten (z.B. Firmware 118, E/A-Einheiten 114 und Speicher 116) durch verschiedene Mittel, einschließlich einer verallgemeinerten Verbindung oder einen Bus 120, Daten aus.
Die Verarbeitungseinheit 101 beinhaltet einen Prozessorkern 122 mit einer Mehrzahl von Registern und Ausführungseinheiten, die Programmanweisungen ausführen, um den Computer zu betreiben. Eine beispielhafte Verarbeitungseinheit beinhaltet den PowerPC™-Prozessor, der durch die International Business Machines Corporation vertrieben wird. Die Verarbeitungseinheit 101 kann auch einen oder mehrere Caches besitzen. Zum Beispiel ist die Verarbeitungseinheit als zwei Caches 126 und 130 aufweisend gezeigt. Caches werden verwendet, um vorübergehend Werte zu speichern, auf die wiederholt durch einen Prozessor zugegriffen wird, um die Verarbeitung zu beschleunigen, indem der längere Schritt eines Ladens der Werte aus dem Speicher 116 vermieden wird.
Die Caches 126 und 130 sind satzassoziative Caches, die es dem Prozessor ermöglichen, eine relativ kurze Zugriffszeit auf einen Teilsatz von Daten oder Anweisungen zu erreichen, die zuvor aus einem Speicher 116 transferiert werden.
Der Cache 126 kann integral mit dem Prozessorkern 122 gepackt sein. Der Cache 126 kann Anweisungsarrays (nicht gezeigt) und Datenarrays 141 aufweisen, die unter Verwendung von Hochgeschwindigkeits-Speichereinheiten realisiert sind. Anweisungen und Daten können an den jeweiligen Cache gerichtet werden, indem ein Signal untersucht wird, das angibt, ob der Prozessorkern eine Operation anfordert, deren Operand eine Anweisung gegenüber Daten ist. Der Cache 126 kann ferner ein Cacheverzeichnis 142 aufweisen, das dem Datenarray 141 zugeordnet ist. Zum Beispiel besitzt jede Cachezeile im Datenarray 141 einen entsprechenden Eintrag im Cacheverzeichnis 142. Das Cacheverzeichnis 142 kann angeben, ob die durch eine effektive Adresse identifizierten Daten im Datenarray 141 gespeichert sind. Zum Beispiel kann dem Cache 126 eine Prozessoranweisung bereitgestellt werden, die eine effektive Adresse referenziert. Wenn sich die effektive Adresse im Cacheverzeichnis 142 befindet, weiß der Prozessor, dass er die referenzierten Daten vom Datenarray 141 bekommen kann, wenn Zugriffskriterien erfüllt sind, wobei Zugriffskriterien erfordern können, dass das gültige Bit gesetzt ist usw. Zum Beispiel beinhaltet die effektive Adresse ein Tagfeld, ein Zeilenindexfeld und ein Bytefeld. Das Tagfeld der effektiven Adresse wird genutzt, um Cache-„Treffer“-Informationen bereitzustellen, wie hierin beschrieben. Das Zeilenindexfeld der effektiven Adresse wird genutzt, um N Cachezeilen z.B. innerhalb des Datencachearrays 141 zu bekommen, die durch das Zeilenindexfeld indexiert sind, wobei N die Anzahl von Sätzen in einem N-assoziativen Cachespeicher ist. Eine der N Cachezeilen kann unter Verwendung einer Satzkennung (als Teil einer Spätauswahl) ausgewählt werden, und das Bytefeld der effektiven Adresse wird genutzt, um ein spezifisches Byte innerhalb der ausgewählten Cachezeile zu indexieren.
Das Datenarray 141 und das Cacheverzeichnis 142 können aus herkömmlichen Speicherarrays aufgebaut sein, wie sie leicht in Konfigurationen von zum Beispiel 4-M- oder 8-M-Chiparrays verfügbar sind. Der Cache 126 ist einer Cachesteuereinheit (nicht gezeigt) zugeordnet, die zum Beispiel den Transfer von Daten zwischen dem Prozessorkern 122 und den Caches verwaltet.
Das Datencachearray 141 besitzt viele Cachezeilen, die einzeln die verschiedenen Datenwerte speichern. Die Cachezeilen sind in Gruppen von Cachezeilen unterteilt, die „Sätze“ genannt werden. Eine beispielhafte Cachezeile beinhaltet ein Zustandsbitfeld, ein Exklusivitätsbitfeld und ein Wertfeld zum Speichern der aktuellen Anweisung oder der aktuellen Daten. Das Zustandsbitfeld und Inklusivitätsbitfelder werden verwendet, um Cachekohärenz in einem Mehrfachprozessor-Computersystem aufrechtzuerhalten. Das Adresstag ist ein Teilsatz der vollen Adresse des entsprechenden Speicherblocks. Eine Vergleichsübereinstimmung einer eingehenden effektiven Adresse mit einem der Tags innerhalb des Adresstagfelds gibt einen Cache-„Treffer“ an. Die Sammlung aller Adresstags in einem Cache (und manchmal das Zustandsbit- und die Inklusivitätsbitfelder) werden als ein Verzeichnis bezeichnet, und die Sammlung aller Wertfelder ist das Cacheeintragsarray.
Der Cache 126 kann als Cache der Ebene 1 (L1) bezeichnet werden, und der Cache 130 kann als ein Cache der Ebene 2 (L2) bezeichnet werden, da er den (L1-) Cache 126 unterstützt. Zum Beispiel kann der Cache 130 als ein Zwischenelement zwischen dem Speicher 116 und dem L1-Cache fungieren und kann eine größere Menge an Informationen (Anweisungen und Daten) speichern als dies der L1-Cache kann, allerdings auf Kosten eines längeren Zugriffs. Zum Beispiel kann der Cache 130 eine Datenspeicherkapazität von 256 oder 512 Kilobyte besitzen, während der L1-Cache 64 Kilobyte an Gesamtdatenspeicher besitzen kann. Der Cache 130 ist mit dem Bus 120 verbunden, und alle Ladevorgänge von Informationen aus dem Speicher 116 in den Prozessorkern 122 können durch den Cache 130 laufen. Obwohl 1 nur eine Cachehierarchie mit zwei Ebenen darstellt, können Mehrebenen-Cachehierarchien bereitgestellt werden, bei denen es viele Ebenen von seriell verbundenen Caches gibt. Zum Beispiel können die Komponenten der Verarbeitungseinheit 101 auf einem einzelnen integrierten Chip gepackt sein.
Ebenfalls in 1 gezeigt ist ein Translation Lookaside Buffer (TLB) 143 zum Übersetzen einer effektiven Adresse in eine entsprechende absolute Adresse. Insbesondere kann der TLB 143 den Seitenzahlabschnitt einer effektiven Adresse in eine entsprechende reale Seitennummer übersetzen. Zum Beispiel kann das Tagfeld einer effektiven Adresse an den TLB 143 gesendet werden, um in eine entsprechende reale Seitennummer übersetzt zu werden.
In einem anderen Beispiel kann das Computersystem 100 mindestens zwei Translation Lookaside Buffers aufweisen, von denen ein erster (TLB1) ein Puffer der ersten Ebene und ein zweiter (TLB2) ein Translation Lookaside Buffer einer zweiten Ebene ist, der angeordnet ist, um den ersten im Falle einer fehlenden Adresse des ersten mit Adressinformationen zu speisen. Zum Beispiel können die Adressübersetzungstabellen im Speicher eine mehrschichtige Struktur sein. Zum Beispiel enthält für eine zweischichtige Tabelle die Tabelle der ersten Ebene, Segmentebene genannt, Einträge, die jeweils ein MB von Speicher durch Verweisen einer Tabelle zweiter Ebene zuordnen, genannt Seitentabelle, die 256 Einträge enthält, die 4 KB an Speicher zuordnen. Der TLB2 kann zwei Typen von Einträgen besitzen: 1-MB-Segmente und einzelne 4-KB-Seiten. Wenn im TLB der ersten Ebene (TLB1) keine Übersetzung verfügbar ist, wird der TLB2 nach einem 4-KB-Seiteneintrag durchsucht, der die erforderliche Übersetzung bereitstellt. Falls nicht, wird der TLB2 nach einem Segmenteintrag für das Segment durchsucht, das die zu übersetzende Adresse enthält. Wenn solch ein Eintrag gefunden wird, wird die Übersetzung, welche die Tabellen im Speicher verwendet, kurzgeschlossen, weil auf die entsprechende Seitentabelle direkt zugegriffen werden kann, ohne dass auf die Segmenttabelle im Speicher zugegriffen werden muss. Und der TLB1 kann ein zweidimensionales Array von Einträgen aufweisen, z.B. 32 Einträge lang und 4 Einträge breit. Jeder Eintrag enthält eine virtuelle Adresse, die übersetzt wurde, und die reale Adresse, in die sie übersetzt wurde. In diesem Beispiel kann der TLB 143 der TLB1 sein.
In einem bestimmten Beispiel kann das Computersystem 100 als eine Hardwareressource in einer virtualisierten Umgebung verwendet werden, wie beispielsweise z/VM von IBM. Zum Beispiel kann die Verarbeitungseinheit 101 Anforderungen von virtuellen Maschinen oder einem Gast empfangen, der unter einem Hypervisor in einer logischen Partition läuft.
2 ist ein Blockschaubild, das ein Schaubild zum Zugreifen auf eine Cachestruktur 200 eines Cachespeichers mit Zweiebenencache über eine effektive Adresse (oder logische Adresse oder virtuelle Adresse) 201 gemäß einem Beispiel der vorliegenden Offenbarung veranschaulicht. Der Cachespeicher ist ein satzassoziativer Cache, der zum Beispiel m Sätze in L1-Cache und n Sätze in L2-Cache aufweist, m kann gleich n sein, muss dies aber nicht. Die Cachestruktur 200 weist einen L1-Cache 226 und einen L2-Cache 230 auf. Der L1-Cache 226 weist, wie mit Bezugnahme auf 1 beschrieben, das Datencachearray 141 und das Cacheverzeichnis 142 auf. In 2 weist der L1-Cache 226 ferner ein Satzverzeichnis 203 und ein Validierungsverzeichnis 205 auf. Der L2-Cache 230 weist ein Cacheverzeichnis 242 und ein Cachearray (nicht gezeigt) auf.
Das Satzverzeichnis 203 ist unter Verwendung von Zeilenindexbits des Zeilenindexfelds 210 der effektiven Adresse 201 indexiert und unter Verwendung einer ersten Gruppe von Bits 212a des Tagfeldes 212 der effektiven Adresse 201 logisch getagt. Das Validierungsverzeichnis 205 ist unter Verwendung von Zeilenindexbits des Zeilenindexfeldes 210 der effektiven Adresse 201 und Satzbits logisch indexiert. Das Validierungsverzeichnis 205 ist unter Verwendung einer zweiten Gruppe von Bits 212b des Tagfeldes 212 der effektiven Adresse 201 logisch getagt. Die erste und die zweite Gruppe von Bits 212a und 212b sind für Erklärungszwecke nicht überlappend gezeigt. Die erste Gruppe und die zweite von Bits können sich überlappen. Zum Beispiel kann die zweite Gruppe von Bits die Bits 0:49 aufweisen, was es ermöglichen kann, Satzverzeichnis-Aktualisierungsregeln zu haben, die entspannt sind, was z.B. erlaubt, dass das Satzverzeichnis und das Validierungsverzeichnis nicht zu jeder Zeit streng synchronisiert sein müssen.
Jeder Eintrag des Satzverzeichnisses 203 weist mindestens die erste Gruppe von Bits 212a und ein gültiges Bit auf. Wenn zum Beispiel der Prozessorkern Threads (z.B. Threads th1 und th2) unterstützt, kann der Eintrag ein gültiges Bit aufweisen, dass jedem Thread zugeordnet ist (z.B. kann der Eintrag wie folgt lauten: LA.37:49, th0 vld, th1 vld). Jeder Eintrag des Validierungsverzeichnisses 205 weist mindestens die zweite Gruppe von Bits auf. In einem bestimmten Beispiel weist der Eintrag des Validierungsverzeichnisses 205 ferner ein gültiges Bit, ein Exklusivitätsbit und einen Schlüssel auf. Das gültige Bit gibt an, dass der Eintrag gültig ist. Das Exklusivitätsbit gibt an, dass die Cachezeile exklusiv besessen wird. Es wird Exklusivitätsbit genannt, weil kein anderer Kern eine Kopie der zugeordneten Zeile haben kann, wenn ein bestimmter Kern eine Zeile exklusiv hat. Cachezeilen werden exklusiv angefordert, wenn Daten geändert werden. Und viele Kerne können eine Zeile in einem Nur-Lese-Zustand haben. Der Schlüssel ist ein Datenspeicherschlüssel zum Schutz und kann jeden anderen Satz von sonstigen Informationen beinhalten. In einem bestimmten Beispiel weist der Eintrag des Validierungsverzeichnisses 205 ferner ein ASCE-Element und ein REAL-Element auf, wobei sich ASCE auf ein Adressraum-Steuerelement (address space control element) (Zeiger auf dynamische Adressübersetzungstabellen) bezieht und das REAL-Element angibt, dass der Eintrag ein realer Eintrag ist.
Die L1- und L2-Cachearrays 141 speichern die Datenkopie aus dem Speicher 116, und jeder Eintrag in den L1- und L2-Verzeichnissen 142 und 242 speichert die zweite Gruppe von Bits 212b, die Adressraumkennung usw. Das L1-Verzeichnis 142 enthält zum Beispiel die folgenden Felder: gültiges Bit, logische Adresse, z.B. 45:49, und L2-Satz-ID. Das gültige Bit gibt an, dass der L1-Verzeichniseintrag gültig oder nicht gültig ist. Die logische Adresse 45:49 ist eine Erweiterung der logischen L1-Adresse 50:55, um den Zugriff auf das L2-Verzeichnis zu erlauben. Die L2-Satz-ID gibt an, welcher L2-Verzeichnissatz den L1-Cacheeintrag enthält. Zum Beispiel kann ein Eintrag des L1-Verzeichnisses 142 wie folgt lauten: setO - L2CC(45:49), th0 logdir vld, th1 logdir vld, ptrdir vld, wobei L2CC(45:49) die Bits 45:49 der effektiven Adresse sind (auch als logische Adresse bezeichnet). Bit 45 wird nur für Datencache gespeichert, weil L2 für Daten von der Größe 4M ist, während L2 für Anweisungen von der Größe 2M ist. „logdir vld“ gibt an, dass die im L1-Cache gespeicherte Übersetzung gültig ist. „ptrdir vld“ ist ein gültiges Bit, das angibt, dass die Daten im L1-Cache gültig sind. Die Bits „45:49“-Bits können zum Beispiel aus den Cachegrößen abgeleitet werden (z.B. die Anzahl von Zeilen). Wenn zum Beispiel der L1-Cache 64 Zeilen pro Satz besitzt, lautet der Zeilenindex 50:55, und wenn L2 1024 Zeilen pro Satz besitzt, kann das Indexieren breiter sein, was zu einem Index von 45:55 führt. Da jedoch das L1-Verzeichnis bereits mit 50:55 indexiert wurde, kann das Verweisen auf eine L2-Koordinate durchgeführt werden, indem nur LA.46:49 und die L2-Satz-ID im Eintrag des L1-Verzeichnisses beibehalten wird.
Um die Beschreibung von 2 zu vereinfachen, kann ein vereinfachtes Beispiel von L1-Cache betrachtet werden. In diesem Beispiel besitzt der L1-Cache 64 Zeilen und 8 Sätze (d.h. m = 8), und eine Cachezeile wird unter Verwendung einer logischen Adresse mit 64 Bits (0:63) adressiert (abgekürzt LA(0:63)). Daher beträgt in diesem Beispiel die Zeilengröße 256 Bytes. In diesem Beispiel kann das Satzverzeichnis 203 LA(37:49) als ein Tag verwenden (die erste Gruppe von Bits). Das Tag des Validierungsverzeichnisses 205 kann LA(0:49) oder LA(0:36) sein, plus zusätzliche Informationen, die erforderlich sind, um zwischen unterschiedlichen Adressräumen zu unterscheiden.
Das Validierungsverzeichnis 205 kann als ein „gestapeltes“ logisches Verzeichnis bezeichnet werden, da das Validierungsverzeichnis aus einer physischen Arraystruktur aufgebaut ist, die einen Verzeichniseintrag pro Zeile speichert. Dem vorstehenden Beispiel folgend weist das Validierungsverzeichnis 8 x 64 Zeilen = 512 Zeilen auf, anstatt acht Arraystrukturen, die jeweils 64 Zeilen besitzen. Der Vorteil solch einer Struktur kann darin liegen, dass eine Arrayzeile nur eine begrenzte Anzahl von Bits besitzen kann (aus physischen Gründen). Ein Hinzufügen von mehr Zeilen schließt einen vergleichsweise geringen Aufwand relativ zum Erweitern der Breite einer Zeile oder dem Hinzufügen von mehr Arraystrukturen ein. Der „gestapelte“ Ansatz kann vorteilhaft sein, da er weniger Fläche und Leistung verbraucht. Das L1-Cacheverzeichnis 142 besitzt jedoch eine Acht-Array-Struktur, die jeweils 64 Zeilen besitzt.
2 veranschaulicht ferner Details der Struktur des L1-Cacheverzeichnisses 142 und des L2-Cacheverzeichnisses 242. Das L1-Cacheverzeichnis 142 weist eine satzassoziative Verzeichnisstruktur mit mehreren L1-Sätzen auf, z.B. eine Anzahl m von L1-Sätzen und jeweilige Vergleicher L1CP1 bis L1CPm. Das L2-Cacheverzeichnis 242 weist eine satzassoziative Verzeichnisstruktur mit mehreren L2-Sätzen auf, z.B. eine Anzahl n von L2-Sätzen und jeweilige Vergleicher L2CP1 bis L1CPn. Das L2-Cacheverzeichnis 242 verwendet Teile der effektiven Adresse 201 als Index und die absolute Adresse als Tag.
Zum Beispiel kann ein Eintrag des L2-Verzeichnisses das Folgende aufweisen: „set0 - AA.17:51“, wobei setO der Satzindex des Satzes ist, der den Eintrag aufweist, AA die absolute Adresse ist, die der effektiven Adresse zugeordnet ist, die verwendet wird, um das L2-Verzeichnis zu indexieren. In einem anderen Beispiel kann der Eintrag des L2-Verzeichnisses ferner zwei zusätzliche Elemente „key(0:3), FP“ aufweisen, wobei „key“ ein 4-Bit-Tag ist, das gemäß den in den Architekturprinzipien (z.B. z/Architecture) des Betriebs des Computersystems 100 beschriebenen Regeln passen muss, und FP (fetch protection) das Schlüsselvergleichen ermöglicht.
Die Cachestruktur 200 weist ferner den TLB 143 auf.
Bei einem Cachenachschlagen empfängt das Satzverzeichnis 203 als Eingabe den Index LA(50:55) und eine erste Gruppe von Bits LA(37:49), und das Satzverzeichnis 203 erzeugt den Satz mit einer Satz-ID, die als Satz(0:7) bezeichnet wird, der die angeforderte Cachezeile speichert, oder sagt diesen voraus. Zum Beispiel kann das Satzverzeichnis 203 durchsucht werden, um die Satz-ID zu finden. Bei Verwenden der Satz-ID Satz(0:7) zusätzlich zum Index LA(50:55) wird im Validierungsverzeichnis 205 nachgeschlagen, um den Cachetreffer unter Verwendung eines Tagvergleichens 220 zu bestätigen, was zu einem Identifizieren eines entsprechenden Verzeichniseintrags im Validierungsverzeichnis 205 führen kann. Dafür wird zum Beispiel die durch das Satzverzeichnis 203 bestimmte Satz-ID verwendet, um eine der acht 64-Zeilen-Sektionen auszuwählen, und LA(50:55) wird verwendet, um die Zeile innerhalb der Sektion auszuwählen
Parallel zum Durchsuchen des Satzverzeichnisses 203 wird im L1-Cacheverzeichnis 142 nachgeschlagen, um das gültige Bit für diesen Verzeichniseintrag abzurufen. Die gültigen Teile sind Teil des L1-Cacheverzeichnisses 142, weil möglicherweise mehrere Einträge gleichzeitig für ungültig erklärt werden müssen. Wenn das Tagvergleichen 220 einen Treffer 244 wahrnimmt und das gültige Bit gesetzt ist, gibt das Gültigkeitsvergleichen 240 an, dass ein Cachetreffer gefunden wurde. Andernfalls kann ein Cachefehler 245 gefunden werden. Das Datenarray 141 kann eine Satzkennung von den Satzverzeichnis 203 empfangen und kann Daten der angeforderten Cachezeilen unter Verwendung des Zeilenindex 210 und des Byteversatzes 213 der effektiven Adresse 201 und der Satzkennung bereitstellen. Im Falle eines Cachefehlers kann eine Warnung bereitgestellt werden, um anzugeben, dass die bereitgestellten Daten einem Cachefehler entsprechen
Nur im Falle eines gefundenen Cachefehlers 245 oder im Falle, dass die Suche im Satzverzeichnis 203 fehlschlägt (zu einem Cachefehler führt), werden die Datenstrukturen im unteren Teil von 2 einbezogen. Namentlich wird im TLB 143 unter Verwendung der effektiven Adresse 201 und unter Verwendung des Treffervergleichens 251 nachgeschlagen (einschließlich Teile der logischen Adresse 201 und übersetzungsrelevanter Informationen, wie beispielsweise eine Adressraumkennung), die absolute Adresse für die Anforderung wird ermittelt. Das Treffervergleichen 251 kann durch eine eigene Vergleichslogik des TLB durchgeführt werden. Parallel zum Durchsuchen des TLB 143 wird im L2-Cacheverzeichnis 242 nachgeschlagen, z.B. unter Verwendung der Bits 46:55 der effektiven Adresse 201. Und das Treffervergleichen 261 sucht nach einem Treffer im L2-Cacheverzeichnis 242 durch Vergleichen der durch den TLB ausgegebenen absoluten Adresse mit den absoluten Adressen des L2-Cacheverzeichnisses, die unter Verwendung der logischen Adresse 201 identifiziert wurden. Das Ergebnis des Treffervergleichens 261 ist eine Angabe darüber, welcher L2-Satz den Treffer wahrgenommen hat (die Zeichnung geht von 8 Sätzen (d.h. n = 8) im L2-Cache aus). Diese Trefferinformationen werden dann im L1-Verzeichnisvergleichen 270 verwendet, um zu sehen, ob die Zeile, die in den L2-Cache trifft, auch bereits im L1-Cache gespeichert ist. Dafür verwendet das L1-Verzeichnisvergleichen 270 auch empfangene logische Eingangszeiger (als out1 bis outm bezeichnet) zum L2-Cache. Jeder logische Zeiger (z.B. Out1) ist einem jeweiligen L1-Satz zugeordnet und weist den L2-Index und die L2-Satz-ID und das gültige Bit des Eintrags des L1-Verzeichnisses auf, der dem Index LA(50:55) entspricht.
3 ist ein Ablaufplan eines Verfahrens zum Betreiben des Cachespeichers von 2. Bei Empfangen einer Zugriffsanforderung z.B. über eine effektive oder logische Adresse, um auf eine gegebene Cachezeile zuzugreifen, wird in Schritt 310 auf das Satzverzeichnis 203 (als setp bezeichnet) und das L1-Cacheverzeichnis 142 (als ptrdir bezeichnet) zugegriffen. Der Zugriff kann zum Beispiel parallel erfolgen. Der Zugriff auf das Satzverzeichnis 203 und das L1-Cacheverzeichnis 142 wird unter Verwendung der Zeilenindexbits der effektiven Adresse (z.B. LA(50:55)) durchgeführt. Der Zugriff auf das Satzverzeichnis 203 kann zu einer Satzkennung führen, muss dies aber nicht, die den Satz angibt, in dem die Cachezeilen vorhanden sind. Der Zugriff auf das L1-Cacheverzeichnis 142 kann zu mehreren Einträgen jeweiliger L1-Sätze führen, muss dies aber nicht, da das L1-Cacheverzeichnis als Eingabe nur die Zeilenindexbits der effektiven Adresse verwendet.
Im Falle (Abfrage 220) eines Cachefehlers, der aus dem Durchsuchen des Satzverzeichnisses 203 herrührt, können Schritte 380 bis 387 durchgeführt werden. Im Falle (Abfrage 220) eines Cachetreffers können Schritte 330 bis 370 durchgeführt werden, und das Satzverzeichnis 203 kann eine Satzkennung bereitstellen, die den Satz angibt, in dem die angeforderte Cachezeile vorhanden ist.
In Schritt 330 kann das Validierungsverzeichnis 205 (als logdir bezeichnet) unter Verwendung der Satzkennung, die vom Satzverzeichnis 203 kommend empfangen wird, und den Zeilenindexbits der effektiven Adresse (z.B. LA(50:55)) durchsucht werden.
In Schritt 340 kann das der adressierten Cachezeile zugeordnete gültige Bit ermittelt werden. Dies kann ermittelt werden, indem der Eintrag der mehreren Einträge unter Verwendung der Satzkennung ausgewählt wird und der Wert des gültigen Bits des ausgewählten Eintrags gelesen wird.
Im Falle (350), dass das Validierungsverzeichnis 205 einen Cachefehler als Ergebnis des Suchens 330 bereitstellt oder das gültige Bit einen Wert besitzt, der einen ungültigen Zustand angibt, kann der Eintrag des Satzverzeichnisses, das durch die Suche von Schritt 310 getroffen wurde, für ungültig erklärt werden 370. Andernfalls kann ein Cachetreffer in Schritt 360 aufgelöst werden, z.B. durch Bereitstellen eines Treffersignals.
In Schritt 380 erfolgt ein TLB-Nachschlagen unter Verwendung der logischen Adresse der Anforderung. Das Ergebnis dieses Nachschlagens ist die passende absolute Adresse. Als Nächstes wird in Schritt 381 im L2-Cacheverzeichnis 242 nachgeschlagen und mit der absoluten Adresse verglichen, wie sie vom TLB geliefert wurde. Im Falle eines L2-Fehlers verzweigt Schritt 382 zu 383, um den L1-Fehler und den L2-Fehler aufzulösen. Nach Auflösen des L1-Fehlers und des L2-Fehlers werden alle Datenstrukturen aktualisiert, so dass die Cachezeile bei der nächsten Anforderung im Satzverzeichnis 203 gefunden werden kann.
Wenn Schritt 382 einen L2-Treffer wahrnimmt, vergleicht Schritt 384 die L1-Cacheverzeichnisinhalte, wie sie durch Suchen des in Schritt 310 gegenüber den L2-Verzeichnisinhalten identifiziert wurden, um zu sehen, ob sich die Cachezeile tatsächlich in L1 befindet. Wenn das Vergleichsergebnis einen L1-Treffer zeigt, entscheidet Schritt 385, sich zu Schritt 386 zu verzweigen. Dies ist der Fall, wenn die Anforderung im Satzverzeichnis 203 keinen Treffer erzielt, sich die Cachezeile aber tatsächlich im L1-Cache befindet. Dies kann zum Beispiel der Fall sein, weil das Satzverzeichnis nicht korrekt ist, oder es könnte sein, weil die derzeitige Anforderung für ein anderes Synonym ist als das Synonym, das bis jetzt im L1 gespeichert wurde (was für die derzeitige Anforderung dasselbe ist, wie zu sagen „das Satzverzeichnis war nicht korrekt“). Auf jede Weise aktualisiert Schritt 386 das Satzverzeichnis 203 und das Validierungsverzeichnis 205, um der derzeitigen Anforderung zu entsprechen. Es muss kein tatsächlicher Datentransfer vorkommen. Wenn Schritt 385 keinen L1-Treffer wahrgenommen hat, gibt dies an, dass die Cachezeile sich nicht im L1-Cache befindet - gleich welches Synonym - sich aber im L2-Cache befindet. Daher wird in Schritt 387 der L1-Fehler aufgelöst, was ein Transferieren von Daten von L2 zu L1 beinhaltet und ein Aktualisieren des Satzverzeichnisses und Validierungsverzeichnisses, so dass bei der wiederholten Anforderung ein L1-Treffer gefunden wird.
Auf jeden der Schritte 370, 383, 386 und 387 folgt Schritt 399 zum Wiederholen der Anforderung, was zu einem klaren L1-Treffer führt.
4 ist ein Ablaufplan eines Verfahrens zum Auflösen von Synonymen im Cachespeicher von 2 gemäß der vorliegenden Offenbarung.
In Schritt 401 wird eine zweite effektive Adresse (als Synonym B bezeichnet) empfangen. Die zweite effektive Adresse ist ein Synonym einer zuvor verarbeiteten effektiven Adresse, die als Synonym A bezeichnet wird. In anderen Worten wird Synonym B für eine Cachezeile verwendet, während sich ein anderes Synonym A bereits im L1-Cache befindet.
Für Beispielzwecke zeigt 4 die Adressen Synonym A und B in hexadezimal. Der Einfachheit willen sind 20-Bit-Adressen (5 Hexadezimalstellen) gezeigt. In diesem Beispiel ist der Byteindex oder Versatz in die Cachezeile nicht gezeigt. Bits sind von links nach rechts nummeriert (Bit 0 ist das signifikanteste Bit), so dass jede Adresse Bits 0:19 besitzt. Synonym A = 12345 und Synonym B = 67895. In diesem Beispiel kann das Satzverzeichnis 203 unter Verwendung von Bits 16:19 indexiert werden (d.h. die letzte Hexadezimalstelle der Adresse) und kann unter Verwendung von Bits 8:15 getagt werden. Wie in 4 gezeigt, sind drei Beispielanwendungsfälle A) bis C) 430 dargestellt.
Im Anwendungsfall A) haben die Synonyme A und B denselben Index (setp index = 5) und haben unterschiedliche Tags im Satzverzeichnis 203. Die Synonyme A und B sind derselben absoluten Adresse zugeordnet.
Im Anwendungsfall B) haben die Synonyme A und B denselben Index (setp index = 5) und haben dieselben Tags im Satzverzeichnis 203. Die Synonyme A und B sind derselben absoluten Adresse zugeordnet.
Im Anwendungsfall C) haben die Zeilen A und B denselben Index (setp index = 5) und haben dieselben Tags im Satzverzeichnis 203. Sie sind jedoch unterschiedlichen absoluten Adressen zugeordnet.
In Schritt 403 wird das Satzverzeichnis durchsucht, um einen Cachetreffer für das angeforderte Synonym B zu identifizieren. Dies wird als ein Fall von „Satzverzeichnis falsch“ betrachtet, weil das Satzverzeichnis 203 einen Satz bereitgestellt hat, der letztendlich nicht wirklich einen Treffer wahrgenommen hat.
Die Suche in Schritt 405 nach Synonym B im Validierungsverzeichnis 205 würde jedoch zu einem Cachefehler führen. Wenn das Nachschlagen nach Synonym A erfolgen würde, würde die Suche im Validierungsverzeichnis 205 einen Treffer wahrnehmen (und Schritt 360 kann ausgeführt werden). Da der Zugriff jedoch für Synonym B erfolgte, wird die Adresse, wie sie aus dem Validierungsverzeichnis 205 gelesen wird, nicht mit der angeforderten Adresse übereinstimmen.
In Schritt 407 wird der Eintrag, der im Satzverzeichnis 203 Synonym B entspricht, für ungültig erklärt. Und der wiederholte Zugriff unter Verwendung von Synonym B wird in Schritt 409 ausgelöst.
Schritte 403 bis 420 werden für die Anwendungsfälle B) und C) ausgeführt.
In Schritt 411 wird das Satzverzeichnis 203 durchsucht, um einen Cachefehler für das angeforderte Synonym B zu identifizieren.
Bei Identifizieren des Cachefehlers von Schritt 411 wird Schritt 413 ausgeführt. In Schritt 413 (der Schritt 384 durchführt) werden die L1-Cacheverzeichnisinhalte, die Synonym B zugeordnet sind, mit den L2-Cacheverzeichnisinhalten verglichen, die Synonym B zugeordnet sind, um herauszufinden, dass sich die Cachezeile tatsächlich in L1 befindet.
Beim Identifizieren oder Finden des Cachetreffers in Schritt 314 können in Schritt 415 das Satzverzeichnis 203 und das Validierungsverzeichnis 205 aktualisiert werden. Die Aktualisierung kann zum Beispiel durchgeführt werden, indem Synonym-A-Informationen mit Synonym B überschrieben werden.
Beim Durchführen der Aktualisierung von Schritt 415 kann in Schritt 417 die Wiederholung des Zugriffs unter Verwendung des Synonyms B ausgelöst werden. Der wiederholte Zugriff führt in Schritt 428 zu einem Satzverzeichnistreffer gefolgt von einem Validierungsverzeichnistreffer in Schritt 419, was dazu führt, dass der Cachezugriff in Schritt 420 aufgelöst wird.
Schritte 411 bis 420 können für Anwendungsfall A) ausgeführt werden. Wenn zum Beispiel Synonym B von Anwendungsfall A) empfangen wird, kann ein Fehler wie in Schritt 411 gefunden werden. In anderen Worten werden für ein empfangenes Synonym B von Anwendungsfall A) möglicherweise nur die Schritte 411 bis 420 ausgeführt.
5 ist ein Ablaufplan eines Verfahrens zum Steuern des Zugriffs auf einen Cachespeicher, z.B. 200, über eine effektive Adresse, z.B. 201, die ein Tagfeld 212 und ein Cachezeilen-Indexfeld 210 aufweist.
In Schritt 501 können eine erste Gruppe von Bits 212a und eine zweite Gruppe von Bits 212b des Tagfeldes 212 ermittelt werden.
In Schritt 503 können die Zeilenindexbits und die erste Gruppe von Bits 212a der effektiven Adresse im Satzverzeichnis 203 gesucht werden, wodurch eine Satzkennung zum Angeben des Satzes erzeugt wird, der eine Cachezeile der effektiven Adresse 201 enthält.
In Schritt 505 können die Satzkennung und die Zeilenindexbits 210 und die zweite Gruppe von Bits 212b der effektiven Adresse 201 im Validierungsverzeichnis 205 gesucht werden, um das Vorhandensein der Cachezeile im Satz mit der in Schritt 503 bereitgestellten Satzkennung zu verifizieren. Dieser Schritt 505 kann das Vorhandensein oder Nichtvorhandensein der Cachezeile in dem Satz angeben oder bestätigen, indem angegeben wird, ob sie im Validierungsverzeichnis 205 vorhanden ist.
Als Reaktion auf das Feststellen des Vorhandenseins der Cachezeile in dem Satz auf Grundlage des zweiten Suchens von Schritt 505 kann in Schritt 507 ein Treffersignal erzeugt werden. Das Treffersignal kann verwendet werden, um die Daten der Cachezeile aus dem Datenarray 141 bereitzustellen.
In einem bestimmten Beispiel können Schritt 503 und/oder Schritt 505 zu einem Cachefehler dahingehend führen, dass die gesuchten Adressen nicht im Satzverzeichnis 203 bzw. im Validierungsverzeichnis gefunden werden. In diesem Fall kann der Cachefehler bestätigt werden, indem auf den TLB 143 und das sekundäre Cacheverzeichnis 242 zugegriffen wird, wie bei den Schritten 380 bis 399 beschrieben.
TLB-UNGÜLTIGKEITSERKLÄRUNGEN
Gemäß einer bestimmten Ausführungsform weist das Verfahren ferner als Reaktion auf ein Empfangen einer Anforderung zum Ungültigkeitserklärung eines Validierungsverzeichniseintrags des Validierungsverzeichnisses ein dementsprechendes Setzen eines gültigen Bits des entsprechenden primären Cacheverzeichniseintrags in dem primären Cacheverzeichnis auf.
Gemäß einer bestimmten Ausführungsform weist das Verfahren ferner ein Bereitstellen einer ersten Hilfsdatenstruktur in Verbindung mit dem primären Cacheverzeichnis auf, wobei jeder Eintrag der ersten Hilfsdatenstruktur Bits der effektiven Adresse aufweist, die Informationen widerspiegeln, die in TLB-Löschungsanforderungen des Multiprozessorsystems angegeben sind, die einen Eintrag in der ersten Hilfsdatenstruktur identifizieren, welcher der empfangenen Anforderung entspricht, wobei der identifizierte Eintrag den primären Cacheverzeichniseintrag angibt.
Wenn zum Beispiel ein Adressraum für ein Gastbetriebssystem durch einen entsprechenden Hypervisor entfernt wird, befinden sich die Cachezeilen noch im L1-Cache. Es gibt jedoch keine gültige Übersetzung für sie mehr. Dies bedeutet, dass die Daten im L1-Cache durch eine Anforderung, welche die entfernte Übersetzung verwendet, nicht mehr zugänglich sein sollten. Um diese Einträge unzugänglich zu machen, sollten sie im L1-Cache für ungültig erklärt werden, weil das L1-Cacheverzeichnis logisch getagt ist. Vor der Ungültigkeitserklärung sollten die betroffenen Einträge gesucht werden. Zum Beispiel kann ein Bit als Teil der Eintragsinformationen im Validierungsverzeichnis verwendet werden, um anzugeben, dass ein bestimmter Eintrag zu einem Gastbetriebssystem gehört. Wenn die TLB-Ungültigkeitserklärung alle Übersetzungsinformationen bezüglich dieses Gastbetriebssystems entfernt, sollten alle Verzeichniseinträge im Validierungsverzeichnis 205 mit dem gesetzten Gastbit für ungültig erklärt werden.
Beim Validierungsverzeichnis 205 kann jeweils nur ein einziger Eintrag nachgeschlagen werden, um herauszufinden, ob er für ungültig erklärt (oder gelöscht) werden sollte. Um dieses Problem zu mildern, wird das L1-Verzeichnis 142 mit einer Nebenstruktur „ptrdirext“ (d.h. der ersten Hilfsdatenstruktur) erweitert, die übersetzungsrelevante Informationen für jeden Eintrag im Validierungsverzeichnis 205 speichert. Wie beim L1-Verzeichnis kann in der ersten Hilfsdatenstruktur auf alle Sätze parallel zugegriffen werden. Zum Beispiel kann ein Eintrag der ersten Hilfsdatenstruktur „set0 - th ASCE(44:49), PGSZ(0:1), SX(37:43)“ aufweisen, wobei sich PGSZ auf eine Seitengröße bezieht (z.B. können dynamische Adressübersetzungsergebnisse für Seitengrößen von 4k, 1M oder 2G sein), sich SX(37:43) auf Bits 37:43 der effektiven Adresse bezieht, und ASCE(44:49) Bits 44:49 der effektiven Adresse sind, die als Adressraumkennung durch einen jeweiligen Thread th verwendet werden.
Zum Beispiel kann eine Sequenz von virtuellen Adressen, die virtuellem Datenspeicher zugeordnet ist, auf den durch ein Adressraum-Steuerelement (ASCE) verwiesen wird, ein Adressraum genannt werden. Adressräume können verwendet werden, um Isolationsgrade zwischen Benutzern bereitzustellen. Die Struktur der ersten Hilfsdatenstruktur kann es ermöglichen, Einträge, die einem gegebenen Adressraum zugeordnet sind, unter Verwendung der ASCE-Bits in einer effizienteren Weise zu löschen.
Bei dieser Nebenstruktur können TLB- Ungültigkeitserklärungen, die nur bestimmte Übersetzungen betreffen sollten, signifikant schneller vorgenommen werden als durch einzelnes Bereinigen aller Einträge im Validierungsverzeichnis.
Die Nebenstruktur ptrdirext wird zusammen mit einer etwaigen Aktualisierung in das Validierungsverzeichnis 205 geschrieben. Ein Ausgleich kann zwischen der Größe des ptrdirext und der Genauigkeit von TLB- Ungültigkeitserklärungen vorgenommen werden. Um den Fall von Gast- gegen Hypervisorbesitz zu lösen, wird ein einzelnes Bit benötigt, um die Unterscheidung vorzunehmen. Wenn eine TLB-Löschung auf Grundlage einer Adressraumkennung, wie beispielsweise dem ASCE in der z/Architecture, d.h. ein 51-Bit-Wert plus einige Steuerinformationen, vorgenommen wird, kann es genug sein, nur einige wenige Bits oder einen Hashwert mancher Bits zu speichern, um herauszufiltern, welche Einträge gelöscht werden müssen und welche nicht. Eine Beispielrealisierung des ptrdirext kann einen Teil der ASCE-Bits, Gastebenen-Kennungsbits, eine Seitengrößenangabe (für TLB-Architekturen, die mehrere Seitengrößen unterstützen), einen Segmentindex oder einen Teil des Segmentindexes speichern (für TLB-Architekturen die Mehrfachebenen-Seitentabellen unterstützen, wobei eine höhere Ebene die „Segmenttabelle“ genannt wird, und Ungültigkeitserklärungen auf Grundlage der Segmenttabelle möglich sind). Wenn zum Beispiel das gültige Bit Teil der L1-Verzeichniseinträge ist, kann die tatsächliche Ungültigkeitserklärung von Einträgen auch parallel für alle Einträge eines Satzes in einem gegebenen L1-Verzeichnis vorgenommen werden.
Zum Zweck des Beschreibens der folgenden Figuren wird die folgende Terminologie verwendet.
Tatsächlicher Speicherzugriff erfolgt unter Verwendung einer „realen“ Adresse. Dies könnte zum Beispiel ein 64-Bit-Wert sein, der Hauptspeicherorte adressiert. Es kann jedoch jeder Wert oder Ansatz zu einem Adressiersystem verwendet werden.
Auf dem Prozessorkern laufende Abweisungen verwenden „logische“ Adressen. Wenn eine dynamische Adressübersetzung (DAT) nicht verwendet wird, läuft der Prozessor im „realen“ Adressiermodus, und die durch das Programm verwendete logische Adresse wird auch als die reale Adresse verwendet.
Wenn DAT verwendet wird, läuft der Prozessor im „virtuellen“ Adressiermodus. Virtuelle Adressierinformationen beinhalten die logische Adresse wie durch Anweisungen spezifiziert plus zusätzliche Informationen, um einen bestimmten Adressraum zu identifizieren, wie beispielsweise ein Adressraum-Steuerelement (ASCE), das zum Beispiel in der durch International Business Machines (IBM) angebotenen z/Architecture zu finden ist. Es können jedoch andere Übersetzungsansätze von virtuell zu real verwendet werden. Dieser virtuelle Adressiermodus kann verwendet werden, um jedem Programm seinen eigenen Adressraum zu geben, unter Verwendung unterschiedlicher Adresszuordnungen von logisch zu real.
VIRTUELLER CACHE
Das („logdir“) Tag 600 des virtuellen Cacheverzeichnisses 142 (hierin als „logdir“ bezeichnet) speichert alle Informationen bezüglich Übersetzungen, die ein herkömmlicher Translation Lookaside Buffer (TLB) üblicherweise speichern würde. 6 ist eine Schaubildveranschaulichung eines beispielhaften logdir-Tags 600 gemäß Ausführungsformen. Das Tag 600 beinhaltet die logischen Adressbits 601, die als Bits 0:49 veranschaulicht sind, eine Adressraumkennung (hier als „ASCE“ veranschaulicht), eine „reale“ Bitangabe R 603 (die eine Adresse als virtuell oder real markiert), einen Adressindikator von virtuell zu real 604 und potenziell andere Inhalte 605.
In dem oben in Hinsicht auf 1 bis 5 und in der gleichzeitig anhängigen US-Patentanmeldung Nr. 15/625 223 mit dem Titel „Cache structure using a logical directory“ eingereicht am 16. Juni 2017, deren Inhalte hiermit durch Bezugnahme in ihrer Gesamtheit aufgenommen werden, können nicht mehrere Übersetzungen in dem Verzeichnis zur selben Zeit koexistieren.
REALE UND VIRTUELLE ÜBERSETZUNGEN
Betriebssysteme verwenden oft direkt reale Adressen. Das heißt, es ist keine Adressübersetzung erforderlich, um die tatsächlichen Informationen, Anweisungen oder Daten zu finden, die durch den Prozessor gespeichert werden. Im logdir eines virtuellen Cache bedeutet dies, dass der Eintrag als eine „reale“ Adresse markiert wird, indem das „R“-Bit 603 gesetzt wird, um anzugeben, dass keine Adressübersetzung erforderlich ist.
Jedes Programm, das über einem zugeordneten Betriebssystem läuft, pflegt gewöhnlicherweise seinen eigenen Adressraum, zum Beispiel unter Verwendung von DAT, um virtuellen Speicher bereitzustellen. Cachezeilen, auf die auf diese Weise zugegriffen wird, können dadurch identifiziert werden, dass das „R“-Bit 603 gelöscht ist. Das heißt, das „R“-Bit 603 ist gesetzt, um anzugeben, dass die Adresse nicht die reale Adresse ist und dass eine Adressübersetzung erforderlich ist, um die tatsächlichen Informationen, Daten oder Anweisungen ausfindig zu machen, die dieser Cachezeile zugeordnet sind.
Für bestimmte Adressbereiche, die zwischen dem Betriebssystem und Benutzercode gemeinsam genutzt werden (z.B. Programme, die über dem Betriebssystem arbeiten), kann das Betriebssystem eine virtuelle Adresszuordnung für den Benutzercode erzeugen, welche die logische Adresse in dieselbe reale Adresse übersetzt. Es wird zum Beispiel davon ausgegangen, dass eine Adresse 0x1000 verwendet wird, um Informationen zwischen dem Betriebssystem und Benutzercode auszutauschen. Das Betriebssystem greift auf allen Speicher unter Verwendung von realen Adressen zu. Benutzercode greift auf allen Speicher unter Verwendung von virtuellen Adressen zu. Für den Benutzercode wird die logische Adresse 0x1000 der realen Adresse 0x1000 zugeordnet.
7 veranschaulicht einen Prozess für einen Datentransfer durch den gemeinsam genutzten Speicherort, wenn das Bit von virtuell zu real 604 im logdir-Tag 600 nicht vorhanden (z.B. nicht enthalten) ist, aber die virtuelle und die reale Adresse dieselbe Adresse sind. In diesem Ansatz tritt die folgende Sequenz von Ereignissen für einen Datentransfer durch den gemeinsam genutzten Speicherort auf.
Der Prozess beginnt, wenn Benutzercode einen Code in eine virtuelle Adresse speichert. Dies ist in Schritt 710 veranschaulicht. Zum Beispiel kann der Benutzercode einen Funktionscode in die virtuelle Adresse speichern. Zu Zwecken dieser Erläuterung lautet die virtuelle Adresse 0x1000. Es kann jedoch jede Adresse verwendet werden. Um dies zu realisieren, erzeugt das logdir 600 einen virtuellen Verzeichniseintrag für diese bestimmte Cachezeile mit DAT Ein und dem R-Bit Aus an der logischen Adresse von 0x1000 (z.B. eine virtuelle Adresse angebend). Dieser Eintragswert für die Cachezeile gibt an, dass der Adressraum für den Benutzercode steht, der den Code in der Cachezeile speicherte.
Als Nächstes ruft der Benutzercode das zugrundeliegende Betriebssystem auf. Dies ist in Schritt 720 veranschaulicht. Der Benutzercode ruft das zugrundeliegende Betriebssystem unter Verwendung der Protokolle auf, die dem Betriebssystem zugeordnet sind, deren Details hierin nicht detaillierter erläutert werden. In manchen Ausführungsformen wird auf das zugrundeliegende Betriebssystem durch den Benutzercode durch einen Hypervisor zugegriffen, der es virtuellen Maschinen ermöglicht, über dem zugrundeliegenden Betriebssystem ausgeführt zu werden.
Als Reaktion auf den Aufruf von dem Benutzercode liest das Betriebssystem den Code aus der realen Adresse. Dies ist in Schritt 730 veranschaulicht. In diesem Schritt liest das Betriebssystem den Code aus der realen Adresse von 0x1000 (dieselbe wie die virtuelle Adresse). Dies führt zu einem logdir-Fehler. Da der reale Adresszugriff nach einem Eintrag im logdir sucht, bei dem das reale Bit 603 eingeschaltet ist (z.B. R = 1). Insofern sollte das Synonym von R = 0 unter Verwendung des Transload-Prozesses bereinigt werden, der oben in Hinsicht auf 1 bis 5 beschrieben ist. Diese Bereinigung ist in Schritt 740 veranschaulicht. Als ein Ergebnis der Bereinigung wird der logdir-Eintrag für die Cachezeile auf den realen Eintrag für die Cachezeile aktualisiert. Dies führt dazu, dass für die logische Adresse 0x1000 die DAT auf Aus und das R-Bit 603 auf Ein gesetzt wird.
Bei jeder folgenden Iteration, bei der die Benutzercodes einen anderen Funktionscode auf die virtuelle Adresse 0x1000 speichern, wird ein logdir-Fehler auftreten, weil das reale Bit auf Ein gesetzt ist. Dies führt dazu, dass das Synonym erneut bereinigt werden muss und das logdir entsprechend aktualisiert wird. Dies kann sich für jede Verwendung der gemeinsam genutzten Adresse wiederholen. Es sollte festgehalten werden, dass der hierin erläuterte Vergleich des R-Bit 603 notwendig ist, da es möglich ist, einen unterschiedlichen logdir-Eintrag zu haben, wo sich die Zuordnung von logischer Adresse zu realer unterscheidet. Das heißt, die virtuelle Adresse und die reale Adresse sind nicht dieselben logischen Adressen.
Um diese Bereinigungsaktionen des virtuellen/realen Adresssynonyms zu lösen, die oben in Hinsicht auf 7 veranschaulicht wurden, kann ein neues Bit zum logischen Verzeichnis hinzugefügt werden. Dies ist der Indikator von virtuell zu real 604. Dieses Bit 604 kann „V = R“ genannt werden („virtuelle Adresse gleich reale Adresse“). Das „V = R“-Bit 604 ist gesetzt, wenn die reale Adresse, die das Ergebnis einer DAT-Ein-Adressübersetzung ist, dieselbe wie die logische Adresse ist, mit der sie gestartet ist (d.h. die log-Adresse ist die reale Adresse). In dem oben in Hinsicht auf 7 erläuterten Beispiel wäre das „V = R“-Bit als ein Ergebnis des Übersetzens der virtuellen Adresse 0x1000 für Benutzercode in die reale Adresse 0x1000 gesetzt.
Um den Wert des „V = R“-Bits zu setzen, in dem die virtuelle Adresse dieselbe wie die reale Adresse ist, wird der Prozess der Adressübersetzung erweitert. 8 veranschaulicht den Erweiterungsprozess. Schritt 810 veranschaulicht den vorigen bestehenden Adressübersetzungsprozess. Jeder Adressübersetzungsprozess kann bei diesem Schritt realisiert werden. Um in den Übersetzungsprozess einzutreten, wird eine Anforderung nach einer logischen Adresse 801 oder eine real-gegenüber-DAT-Ein-Anforderung 802 empfangen. Als Reaktion auf die Anforderung ermittelt der Prozess, ob es eine Anforderung nach einer realen Adresse gibt. Dies ist in Schritt 820 veranschaulicht. Wenn die Anforderung für eine reale Adresse ist, gibt ein neuer Vergleicher eine „V = R“-Angabe aus, wenn die resultierende reale Adresse und die eingegebene logische Adresse identisch sind. Dies ist in Schritt 830 veranschaulicht.
Zusätzlich wird in Ausführungsformen der TLB 143 um ein „V = R“-Bit in jedem TLB-Eintrag erweitert, so dass ein TLB-Treffer auch die „V = R“-Informationen ausgeben kann. Alternativ dazu kann die „V = R“-Angabe auch nach jedem TLB-Nachschlagen neu berechnet werden. In diesem Ansatz ist es möglich, die zusätzlichen Bits im TLB auf Kosten des Vorhandenseins des „V = R“-Vergleichsprozesses im TLB-Nachschlagepfad einzusparen.
Um Zugriff auf den Eintrag sowohl als eine virtuelle als auch eine reale Adresse zu erlauben, wird die Verzeichnistreffer-Vergleichslogik ebenfalls verbessert. Wenn in Ausführungsformen ein Nachschlagen nach einer „V = R“-Adresse als Teil eines virtuellen Cachenachschlagens erfolgt, wird die normale Verzeichnisvergleichslogik angewandt. Wenn das Nachschlagen jedoch nach einer realen Adresse erfolgt und das „V = R“-Bit im Verzeichniseintrag gesetzt ist, werden alle DAT-ein-Informationen, wie beispielsweise das ASCE, ignoriert. Auf diese Weise kann der Verzeichniseintrag sowohl als ein virtueller als auch ein realer Eintrag verwendet werden. 9 veranschaulicht eine Beispielrealisierung eines Verzeichnisvergleichens einschließlich der „V = R“-Logik der vorliegenden Offenbarung. Unten in der Figur befindet sich ein 3-Wege-UND 910 unten in 9 berechnet die „Treffer“-Informationen für die Cachezeile. Der linke Eingang 920 des UND 910 behandelt den Vergleich der Informationen, die relevant für eine DAT-Ein-Bedingung im logdir sind. Wenn die DAT Ein ist und der Eingang eine Eingabe für den „V = R“-Fall empfängt und wenn es sich um eine Anforderung einer realen Adresse handelt und das „V = R“-Bit gesetzt ist, werden die DAT-Ein-Informationen ignoriert. Der mittlere Eingang 930 des UND 910 empfängt das Ergebnis des Vergleichens der logischen Adresse. Der rechte Eingang 940 des UND 910 qualifiziert das Vergleichen mit dem angeforderten Adressmodus. Entweder ist die Anforderung virtuell und der Verzeichniseintrag ist ebenfalls virtuell oder beide sind real, wobei beim verbesserten V = R die Anforderung real ist und der Eintrag V = R ist. Diese in Hinsicht auf 8 und 9 erläuterte Verbesserung wird als Schritt 750 in den in 7 veranschaulichten Prozess eingefügt. Bei diesem Schritt wird folgend auf die Bereinigung des Synonyms in Schritt 740 das „V = R“-Bit auf einen Wert gesetzt, der angibt, das V = R Ein oder Wahr ist. In manchen Ausführungsformen kann das DAT an diesem Punkt wieder auf Ein gesetzt werden, abhängig von der durch den Benutzercode oder das Betriebssystem verwendeten Logik beim Zugreifen darauf, was sie für virtuelle Adressen halten.
Unter Hinwendung auf 10 bis 17 wird nun ein Prozess zum Verwalten von Übersetzungen über unterschiedliche Threads hinweg erläutert.
ÜBERSETZUNGEN IN UNTERSCHIEDLICHEN THREADS
Das („logdir“-) Tag des virtuellen Cacheverzeichnisses 142 speichert alle Informationen bezüglich Übersetzungen, die ein TLB, wie beispielsweise der TLB 143 üblicherweise speichert. 10 veranschaulicht ein Beispieltag 1000 gemäß veranschaulichenden Ausführungsformen. Das Tag 1000 beinhaltet die logischen Adressbits 0:49 (1001), eine Adressraumkennung 1002 („ASCE“), eine „reale“ Bitangabe 1003 (markiert eine Adresse als „benötigt keine Adressübersetzung“, gewöhnlicherweise für die Verwendung durch Betriebssysteme) und anderen Inhalt, der erforderlich oder hilfreich zum Ermitteln von Cachetreffer gegenüber -fehler ist, kollektiv 1004. In manchen Ausführungsformen kann das Tag das oben in Hinsicht auf 6 bis 9 erläuterte „V = R“-Bit beinhalten.
In manchen Mikroprozessorarchitekturen, wie beispielsweise die von International Business Machines (IBM) angebotene z/Architecture, wird die Adressübersetzungsgültigkeit pro Thread definiert. Daher ist ein Cacheverzeichniseintrag im logdir, der durch einen bestimmten Thread erzeugt wird, nicht notwendigerweise für andere Threads gültig. Der Verzeichnisnachschlageprozess beinhaltet kein Durchführen der tatsächlichen Adressübersetzung. Daher beinhaltet der Verzeichnisnachschlageprozess kein Prüfen, ob die Adressübersetzung derzeit gültig ist. Stattdessen wird die Adressübersetzung bei entweder Erstellung oder Aktualisieren eines Eintrags vorgeformt.
In dem oben in Hinsicht auf 1 bis 5 und in der gleichzeitig anhängigen US-Patentanmeldung Nr. 15/625 223 mit dem Titel „Cache structure using a logical directory“ eingereicht am 16. Juni 2017, deren Inhalte hiermit erneut durch Bezugnahme in ihrer Gesamtheit aufgenommen werden, beschriebenen Ansatz können mehrere Threads unterstützt werden, indem das Verzeichnistag mit einem zusätzlichen Feld erweitert wird, das den Thread angibt, der den Cacheverzeichniseintrag erzeugt hat. Den oben erläuterten Regeln folgend wechselt der Thread-Besitz zwischen Threads (durch Ausführen von „Transloads“), wenn ein anderer Thread als von dem derzeitigen Besitzer des Cacheverzeichniseintrags auf die gemeinsam genutzte Cachezeile zugreifen möchte. Wenn der Wechsel des Besitzes der gemeinsam genutzten Cachezeile häufig geschieht, erzeugt dieses konstante Wechseln des Besitzes der Cachezeile ein Leistungsproblem.
Die vorliegende Offenbarung löst dieses Leistungsproblem durch Hinzufügen von gültigen Bits pro Thread zum Cacheverzeichnis 1005. In der oben erläuterten Gestaltung wird dies durch Hinzufügen von gültigen Bits pro Thread im ptrdir erreicht. Die TLB-Ungültigkeitserklärungen können auch funktionieren, indem nur auf Einträge für den Thread gesehen wird, der die TLB-Ungültigkeitserklärung vornimmt, und nur die gültigen Bits dieses Threads ausgeschaltet werden. Auf diese Weise bleibt die Cachezeile für andere Threads zugänglich, selbst nachdem ein bestimmter Thread seine Übersetzung in diese Zeile „verloren“ hat.
In den vorliegenden Ausführungsformen ist es für einen Thread möglich, eine Cachezeile im L1-Cache zu besitzen, ohne irgendwelche gültigen Übersetzungen für die Cachezeile zu haben. Beide Threads, die auf die Übersetzungen zugreifen, könnten ihre Übersetzungen unabhängig für ungültig erklärt haben lassen, was zu einem Eintrag für eine Cachezeile ohne gültige Übersetzung in sie führt. In manchen Ausführungsformen wird aus mikroarchitektonischen Gründen ein Bit „Cachezeile noch in L1“ gewünscht, ein anderes gültiges Bit („Zeile gültig“) 1006 kann zum Cacheverzeichnis hinzugefügt werden, das nur bei einer vollständigen Cachezeilen-Ungültigkeitserklärung ausgeschaltet werden kann. Eine vollständige Cachezeilen-Ungültigkeitserklärung kann zum Beispiel als ein kreuzweises Ungültigerklären von einem anderen Prozessorkern auftreten. In Ausführungsformen, die diesen Ansatz verwenden, wird eine Cachezeile als für ein gegebenes Nachschlagen gültig betrachtet, wenn das gültige Bit des Nachschlagethreads gesetzt ist, was die Übersetzung in die Cachezeile als gültig identifiziert, und das „Zeile gültig“-Bit gesetzt wird.
Mit dem Hinzufügen von gültigen Bits pro Thread zum Cacheverzeichnis wird der Prozess unten in Hinsicht auf 11 und 12 erläutert, um es zwei Threads zu erlauben, dieselbe Cachezeile unter Verwendung derselben Übersetzung gemeinsam zu nutzen. Der unten erläuterte Prozess geht davon aus, dass zwei unterschiedliche Threads auf dieselbe Cachezeile zugreifen und dass die Cachezeile zu Beginn des Prozesses nicht im L1-Cache aber bereits im L2-Cache war. 13 erläutert und veranschaulicht den vollständigen Entscheidungsprozess von 11 und 12.
11 veranschaulicht gemäß Ausführungsformen einen Prozess eines ersten Threads, der versucht, auf eine bestimmte Cachzeile zuzugreifen. Der Prozess beginnt, wenn der erste Thread feststellt, dass es einen logdir-Fehler im L1-Cache gibt. Dies ist in Schritt 1110 veranschaulicht. Ein logdir-Fehler tritt auf, wenn der Thread versucht, den bestimmten Eintrag im Cacheverzeichnis zu finden. Ein Cachefehler tritt auf, wenn der Thread den L1-Cache nach der spezifischen Cachezeile durchsucht, die Cachezeile aber nicht im L1-Cache findet.
Auf den logdir-Fehler folgend fährt der Prozess damit fort, einen ptrdir-Vergleich durchzuführen. Dies ist in Schritt 1120 veranschaulicht. Bei diesem Schritt stellt der Prozess fest, dass die Cachezeile überhaupt nicht im L1-Cache zu finden ist. Der ptrdir-Vergleich wird durch irgendeinen bekannten Prozess durchgeführt, der für ein Nachschlagen von ptrdir gegenüber dem L2-Verzeichnis/TLB verwendet wird.
Als Nächstes führt der Prozess ein L2-Verzeichnisvergleichen durch, um die gewünschte Cachezeile zu finden. Dies ist in Schritt 1130 veranschaulicht. Bei diesem Schritt stellt der Prozess fest, dass die Cachezeile im L2-Cache vorhanden ist. Wäre die Cachezeile nicht im L2-Cache gefunden worden, würde der Prozess diesen Schritt für den L3-Cache oder irgendeinen untergeordneten Cache wiederholen, der in der Prozessorstruktur vorhanden ist, bis zu dem Zeitpunkt, zu dem er die gewünschte Cachezeile findet. Wenn die Cachezeile im L2-Cache gefunden wird, identifiziert der Prozess diese Cachezeile zum Neuladen in den L1-Cache.
Sobald die Cachezeile in L2 oder einem niedrigeren Cache identifiziert wurde, fährt der Prozess damit fort, einen neuen Verzeichniseintrag für die Cachezeile im L1-Cache zu erzeugen. Dies ist in Schritt 1140 veranschaulicht. Bei diesem Schritt kann der Prozess einen bereits bestehenden Eintrag im Cacheverzeichnis zum Überschreiben wählen. In manchen Ausführungsformen ist der zu überschreibende Eintrag der älteste Eintrag. In manchen Ausführungsformen ist der Eintrag, der überschrieben wird, der Eintrag, auf den für eine Zeitdauer nicht zugegriffen wurde. In anderen Ausführungsformen ist der Eintrag der Eintrag, der die wenigsten Zugriffe besitzt. Es kann jedoch jeder Ansatz zum Auswählen des Verzeichniseintrags zum Überschreiben verwendet werden. Sobald der Verzeichniseintrag zum Überschreiben ausgewählt ist, geht der Prozess dazu über, die L1-Cachedatenstrukturen für die Cachezeile zu aktualisieren, und setzt das Gültigkeitsbit für den Thread, um anzugeben, dass der erste Thread der Besitzer der Cachezeile ist. Zur selben Zeit wird das Gültigkeitsbit für den zweiten besitzenden Thread für die Cachezeile für ungültig erklärt. Die Ungültigkeitserklärung des Gültigkeitsbits für den anderen Thread erfolgt, weil der andere Thread ein gültiges Bit im Verzeichniseintrag gesetzt haben könnte, der überschrieben wird. Die neue Übersetzung (Cachezeileneintrag) ist nicht notwendigerweise auch für den anderen (zweiten) Thread gültig.
Nachdem die Cachezeile in den L1-Cache geladen wurde, kann der erste Thread einen Treffer auf diesem Eintrag erzielen, falls notwendig. Dies ist in Schritt 1150 veranschaulicht. Das heißt, der erste Thread kann auf das zugeordnete logdir im L1-Cache zugreifen und es finden.
12 ist ein Prozessplan, der einen Prozess für einen zweiten Thread zum Nachschlagen des Cacheeintrags auf den Prozess von 11 folgend gemäß Ausführungsformen veranschaulicht. Der Prozess von 12 ist ähnlich zum oben in Hinsicht auf 11 erläuterten Prozess, und für Zwecke der Erläuterung von 12 werden die Details ähnlicher Schritte hier nicht detaillierter erläutert. Der Prozess beginnt, wenn der zweite Thread ein logdir-Nachschlagen durchführt und einen Treffer für das logdir im L1-Cache findet. Dies ist in Schritt 1210 veranschaulicht.
Auf die Feststellung folgend, dass die Cachezeile im L1-Cache war, stellt der Prozess fest, dass die Cachezeile für den zweiten Thread nicht gültig ist. Dies ist in Schritt 1220 veranschaulicht. Die Gültigkeit für den zweiten Thread ist nicht gültig, da die Gültigkeit der Übersetzung für den Eintrag nur für den ersten Thread festgestellt wurde. Der Prozess zum Ermitteln, ob die Cachezeile für den zweiten Thread gültig ist, kann unter Verwendung eines beliebigen bekannten Verfahrens zum Feststellen, dass eine Cachezeile gültig ist, ausgeführt werden.
Da die Cachezeile nicht für den zweiten Thread gültig ist, wird ein ptrdir- und L2-Verzeichnis/TLB-Nachschlagen durchgeführt. Dies ist in Schritt 1230 veranschaulicht. Bei diesem Schritt stellt der zweite Thread fest, dass die Cachezeile im L1-Cache vorhanden ist.
(Durch den Prozess von 11 zu L1 bewegt.) Vom Ort des Cachezeilentreffers wird festgestellt, dass er bei derselben Cachezeile ist, wo in Schritt 1210 der logdir-Treffer gefunden wurde. Dieser Treffer auf derselben Cachezeile bestätigt, dass die Übersetzung bereits im L1-Cache ist, und die Übersetzung mit der Übersetzung für den ersten Thread übereinstimmt.
Das gültige Bit des L1-Cache für den zweiten Thread wird eingeschaltet. Dies ist in Schritt 1240 veranschaulicht. Ferner wird das gültige Bit für den ersten Thread auch auf Ein belassen. Dies führt dazu, dass sowohl der erste Thread als auch der zweite Thread in der Lage sind, die Cachezeile parallel zu verwenden.
13 ist eine Diagrammveranschaulichung, die den kombinierten Prozess von 11 und 12, der als ein Entscheidungsbaum dargestellt ist, gemäß Ausführungsformen veranschaulicht.
Wenn in Schritt 1310 kein logdir-Treffer wahrgenommen wird und in Schritt 1320 kein ptrdir-Treffer wahrgenommen wird, befindet sich die Cachezeile derzeit nicht im L1-Cache. So ermittelt Schritt 1330 auf Grundlage des L2-Verzeichnis-Nachschlageergebnisses, ob die Cachezeile aus dem L2-Cache (Pfad (A)) oder dem L3-Cache (Pfad (B)) nachzuladen ist (detaillierter in Hinsicht auf 14 erörtert).
Wenn jedoch das ptrdir-Vergleichen in Schritt 1320 einen Treffer wahrnimmt, befindet sich die Zeile bereits im L1-Cache. Im Beispiel wird das L1-Verzeichnis so aktualisiert, dass es mit den derzeitigen Informationen des anfordernden Threads übereinstimmt (Schritt 1321). Das gültige Bit für den derzeitigen Thread wird gesetzt, die gültigen Bits für alle andern werden für ungültig erklärt (Schritt 1322). Erneut wird dieser Schritt durchgeführt, weil als ein Ergebnis des Verzeichnisaktualisierens auf die Informationen der derzeitigen Anforderung die Übersetzungsinformationen im Verzeichnis möglicherweise für andere Threads nicht mehr korrekt sind.
Wenn das logdir-Vergleichen einen Treffer zeigt, aber Schritt 1340 das gültige Bit für den anfordernden Threadsatz nicht findet, bewegt sich der Baum zum nächsten zu Schritt 1350 und prüft das ptrdir-Vergleichsergebnis. Wenn kein Treffer wahrgenommen wird, befindet sich die Cachezeile nicht in L1 und Schritt 1360 folgt ähnlich wie Schritt 1330, um die Cachezeile in L1 zu bringen. Wenn das ptrdir-Vergleichen 1350 einen Treffer zeigt, vergleicht Schritt 1370 die ptrdir-Treffer-setid mit der logdir-Treffer-setid aus Schritt 1310. Wenn sie übereinstimmen, befindet sich die Cachezeile der derzeitigen Anforderung bereits in L1 mit der korrekten logdir-Taginformation. Nur das gültige Bit fehlt für den zweiten Thread. Daher wird das gültige Bit für den derzeitigen anfordernden Thread eingeschaltet, und wenn andere gültige Bits bereits aktiv waren, wird die Cachezeile nun zwischen mehreren Threads gemeinsam genutzt. Wenn das setid-Vergleichen 1370 zeigt, dass der L1-Treffer auf einer anderen setid war, wird dieser Eintrag auf die Informationen des derzeitigen anfordernden Thread aktualisiert, das gültige Bit des derzeitigen anfordernden Thread wird gesetzt und die gültigen Bits aller anderen Threads wieder gelöscht. Dies ist in Schritt 1371 veranschaulicht.
14 ist ein Ablaufplan, der das Auflösen eines L1-Cachefehlers gemäß Ausführungsformen veranschaulicht. Ein Eintritt in den Prozess 1400 wird entweder von Pfad A oder Pfad B von 13 erreicht. Pfad A stellt einen L1-Cachefehler und einen L2-Cachetreffer dar, während Pfad B einen L1-Cachefehler und einen L2-Cachefehler darstellt. In Schritt 1401 von Pfad A in den Prozess 1400 eintretend, wird die Cachezeile aus dem L2-Cache geholt. In Schritt 1402 von Pfad B in den Prozess 1400 eintretend, wird die Cachezeile aus dem L3-Cache geholt. Sobald die Zeile geholt ist, schreibt der Prozess in Schritt 1403 alle L2-Datenstrukturen bei jedem wiederholten Nachschlagen als Treffer auf die L3-Cachezeile. Entweder Schritt 1401 oder 1403 folgend (abhängig vom Eintrittspfad) werden die Prozesse zusammengeführt. In Schritt 1410 werden die L1-Datenstrukturen bei jedem nachfolgenden Nachschlagen als Treffer auf diese Cachezeile geschrieben. In Schritt 1420 wird das gültige Bit in dem Cachezeileneintrag für den entsprechenden Thread, der die bestimmte Cachezeile angefordert hat, gesetzt. Das Nachschlagen kann in Schritt 1430 wiederholt werden.
UNTERSCHIEDLICHE ÜBERSETZUNGEN IN UNTERSCHIEDLICHEN THREADS
In einem Simultaneous Multithreading Core (SMT) benötigt jeder Thread potenziell eine eigene Übersetzung für eine absolute Adresse, die zwischen Threads gemeinsam genutzt wird. In dem vorstehend beschriebenen Thread-Sharing-Ansatz führt dies dazu, dass Thread 1 die korrekten Informationen (z.B. logische Adresse, ASCE...) während des L1-Verzeichnisnachschlagens nicht findet. Daher wäre ein Setzen des gültigen Bits für diesen Thread irrtümlich, selbst wenn der Vergleichsprozess von ptrdir gegenüber dem L2-Verzeichnis/TLB zeigt, dass sich die korrekte Cachezeile bereits im L1-Cache befindet. Schließlich würde eine andere Übersetzung (d.h. diejenige von dem ersten Thread) für diese Zeile verwendet werden. In diesem Ansatz kann die Situation so behandelt werden als ob kein gültiges Bit pro Threadverzeichnis in der Cachezeile existieren würde, d.h. Durchführen eines Transload. Der logdir-Eintrag des vorhandenen (ersten) Thread wird mit den Informationen des zweiten Thread überschrieben, und das andere gültige Bit des ersten Thread wird ausgeschaltet.
15 veranschaulicht gemäß Ausführungsformen eine Lösung zum gemeinsamen Nutzen von Cachezeilen in einem logdir, die unterschiedliche Übersetzungen verwenden. Von zwei Threads ausgehend werden die vollständigen Verzeichnistaginformationen des Verzeichnisses dupliziert. Das Tagvergleichsergebnis wird weiter qualifiziert, da die Anforderung für den ersten Thread für das Verzeichnis des ersten Thread ist und da die Anforderung für den zweiten Thread für das Verzeichnis des zweiten Thread ist. Ein Verzeichnistreffer tritt auf, wenn eines der Treffersignale aktiv ist.
In manchen Ausführungsformen ist es nicht notwendig, beide Verzeichnisse mit Strom zu versorgen. Die Thread-ID einer Anforderung wäre früh im Prozess bekannt. Die Kenntnis der entsprechenden Thread-ID kann verwendet werden, um die Strukturen auszuschalten, die für den „anderen“ Thread sind. Während so der logdir-Bereich dupliziert wird, in manchen Ausführungsformen, insbesondere für einen Dual-Thread-Kern, der eher leistungsbeschränkt als flächenbeschränkt ist. Dieser Ansatz beseitigt die Notwendigkeit, das Tagvergleichsergebnis im L1-Cachenachschlagen des Thread zu betrachten, der eine Cachezeile gemeinsam nutzen möchte. Der Thread besitzt seinen eigenen Verzeichniseintrag und muss keinen Abgleich mit dem bestehenden Verzeichniseintrag des anderen Thread durchführen.
16 veranschaulicht einen Ansatz, bei dem manche der Verzeichnisinhalte zwischen Threads gemeinsam genutzt werden. Dieser Ansatz erlaubt nur teilweise unterschiedliche Taginformationen. Somit kann einiges des Aufwands eines Verzeichnisses pro Thread eingespart werden. Der Schlüssel liegt darin, dass abhängig von tatsächlichen Szenarios eines gemeinsamen Nutzens zwischen Threads nicht alle Taginformationen unterschiedlich sind. Zum Beispiel kann Speicher, der zwischen unterschiedlichen Programmen gemeinsam genutzt wird, die in unterschiedlichen Threads laufen, denselben logischen Adressen zugeordnet werden und nur eine andere Adressraumkennung verwenden. In diesem Fall muss nur das ASCE pro Thread unterschiedlich sein. Dies tritt häufig auf, wenn gemeinsam genutzte Bibliotheken verwendet werden.
In manchen Ausführungsformen wird das Tag dann in einen ASCE-Teil, der pro Thread dupliziert ist (im privaten logdir von erstem Thread/zweitem Thread), und die verbleibenden Bits aufgeteilt, die in einem von Threads gemeinsam genutztem logdir gespeichert werden. Erneut müssen für die Anforderung des derzeitigen Thread nur die privaten Strukturen der Threads mit Strom versorgt werden. Der endgültige Treffer wird als ein Ergebnis von Tagtreffern pro Thread und zwischen Threads gemeinsam genutzten Tagtreffern berechnet.
17 ist eine Diagrammveranschaulichung des Entscheidungsbaums gemäß 13, der so modifiziert ist, dass das teilweise gemeinsame Nutzen von Informationen pro Thread im logdir verarbeitet wird. Bezugnahmen auf die Pfade A und B in 17 beziehen sich auf die Pfade von 14. Mit separaten für Threads privaten und zwischen Threads gemeinsam genutzten Teilen im Verzeichnis werden die vorzunehmenden Entscheidungen bei einem Cachenachschlagen geringfügig gegenüber 13 modifiziert. Schritt 1310 wird modifiziert, damit er auf Grundlage des zwischen Threads gemeinsam genutzten Teils des logdir entscheidet. Dies ist in Schritt 1710 veranschaulicht. Schritt 1340 wird modifiziert, damit er auf Grundlage des Ergebnisses des gültigen Bits für den anfordernden Thread und dem privaten logdir-Treffer entscheidet. Dies ist in Schritt 1740 veranschaulicht. Schritt 1371 wird modifiziert, damit er nicht nur das gültige Bit aktualisiert, sondern auch den für den Thread privaten Teil des logdir schreibt. Dies ist in Schritt 1771 veranschaulicht. Wenn das ptrdir-Vergleichen in Schritt 1770 den Treffer in der „falschen“ setid wahrnimmt (z.B. nicht diejenige mit dem zwischen Threads gemeinsam genutzten Treffer), sollte der L1-Verzeichnisinhalt noch aktualisiert werden. Dies schließt sowohl den zwischen Threads gemeinsam genutzten Teil als auch den für den Thread privaten Teil des logdir ein. Dies berücksichtigt ein Aktualisieren des zwischen Threads gemeinsam genutzten Teils, ohne dass das Kennen der gültigen Übersetzung für andere Threads erfordert, dass die gültigen Bits des anderen Thread ausgeschaltet werden sollten.
Aspekte der vorliegenden Erfindung werden hierin unter Bezugnahme auf Darstellungen von Ablaufplänen und/oder Blockschaubildern von Verfahren, Vorrichtungen (Systemen) und Computerprogrammprodukten gemäß Ausführungsformen der Erfindung beschrieben. Es versteht sich, dass jeder Block der Darstellungen von Ablaufplänen und/oder der Blockschaubilder sowie Kombinationen von Blöcken in den Darstellungen von Ablaufplänen und/oder den Blockschaubildern durch computerlesbare Programmanweisungen realisiert werden können.
Bei der vorliegenden Erfindung kann es sich um ein System, ein Verfahren und/oder ein Computerprogrammprodukt handeln. Das Computerprogrammprodukt kann (ein) durch einen Computer lesbare(s) Speichermedium (oder -medien) beinhalten, auf dem/denen durch einen Computer lesbare Programmanweisungen gespeichert ist/sind, um einen Prozessor dazu zu veranlassen, Aspekte der vorliegenden Erfindung auszuführen.
Bei dem durch einen Computer lesbaren Speichermedium kann es sich um eine physische Einheit handeln, die Anweisungen zur Verwendung durch ein System zur Ausführung von Anweisungen behalten und speichern kann. Bei dem durch einen Computer lesbaren Speichermedium kann es sich zum Beispiel um eine elektronische Speichereinheit, eine magnetische Speichereinheit, eine optische Speichereinheit, eine elektromagnetische Speichereinheit, eine Halbleiterspeichereinheit oder jede geeignete Kombination daraus handeln, ohne auf diese beschränkt zu sein. Zu einer nicht erschöpfenden Liste spezifischerer Beispiele des durch einen Computer lesbaren Speichermediums gehören die Folgenden: eine tragbare Computerdiskette, eine Festplatte, ein Direktzugriffsspeicher (RAM), ein Nur-Lese-Speicher (ROM), ein löschbarer programmierbarer Nur-Lese-Speicher (EPROM bzw. Flash-Speicher), ein statischer Direktzugriffsspeicher (SRAM), ein tragbarer Kompaktspeicherplatte-Nur-Lese-Speicher (CD-ROM), eine DVD (digital versatile disc), ein Speicher-Stick, eine Diskette, eine mechanisch kodierte Einheit wie zum Beispiel Lochkarten oder gehobene Strukturen in einer Rille, auf denen Anweisungen gespeichert sind, und jede geeignete Kombination daraus. Ein durch einen Computer lesbares Speichermedium soll in der Verwendung hierin nicht als flüchtige Signale an sich aufgefasst werden, wie zum Beispiel Funkwellen oder andere sich frei ausbreitende elektromagnetische Wellen, elektromagnetische Wellen, die sich durch einen Wellenleiter oder ein anderes Übertragungsmedium ausbreiten (z.B. durch ein Glasfaserkabel geleitete Lichtimpulse) oder durch einen Draht übertragene elektrische Signale.
Hierin beschriebene, durch einen Computer lesbare Programmanweisungen können von einem durch einen Computer lesbaren Speichermedium auf jeweilige Datenverarbeitungs-/Verarbeitungseinheiten oder über ein Netzwerk wie zum Beispiel das Internet, ein lokales Netzwerk, ein Weitverkehrsnetz und/oder ein drahtloses Netzwerk auf einen externen Computer oder eine externe Speichereinheit heruntergeladen werden. Das Netzwerk kann Kupferübertragungskabel, Lichtwellenübertragungsleiter, drahtlose Übertragung, Leitwegrechner, Firewalls, Vermittlungseinheiten, Gateway-Computer und/oder Edge-Server aufweisen. Eine Netzwerkadapterkarte oder Netzwerkschnittstelle in jeder Datenverarbeitungs-/Verarbeitungseinheit empfängt durch einen Computer lesbare Programmanweisungen aus dem Netzwerk und leitet die durch einen Computer lesbaren Programmanweisungen zur Speicherung in einem durch einen Computer lesbaren Speichermedium innerhalb der entsprechenden Datenverarbeitungs-/Verarbeitungseinheit weiter.
Bei durch einen Computer lesbaren Programmanweisungen zum Ausführen von Arbeitsschritten der vorliegenden Erfindung kann es sich um Assembler-Anweisungen, ISA-Anweisungen (Instruction-Set-Architecture), Maschinenanweisungen, maschinenabhängige Anweisungen, Mikrocode, Firmware-Anweisungen, zustandssetzende Daten oder entweder Quellcode oder Objektcode handeln, die in einer beliebigen Kombination aus einer oder mehreren Programmiersprachen geschrieben werden, darunter objektorientierte Programmiersprachen wie Smalltalk, C++ o.ä. sowie herkömmliche prozedurale Programmiersprachen wie die Programmiersprache „C“ oder ähnliche Programmiersprachen. Die durch einen Computer lesbaren Programmanweisungen können vollständig auf dem Computer des Benutzers, teilweise auf dem Computer des Benutzers, als eigenständiges Software-Paket, teilweise auf dem Computer des Benutzers und teilweise auf einem fernen Computer oder vollständig auf dem fernen Computer oder Server ausgeführt werden. In letzterem Fall kann der entfernt angeordnete Computer mit dem Computer des Benutzers durch eine beliebige Art Netzwerk verbunden sein, darunter ein lokales Netzwerk (LAN) oder ein Weitverkehrsnetz (WAN), oder die Verbindung kann mit einem externen Computer hergestellt werden (zum Beispiel über das Internet unter Verwendung eines Internet-Dienstanbieters). In einigen Ausführungsformen können elektronische Schaltungen, darunter zum Beispiel programmierbare Logikschaltungen, im Feld programmierbare Gatter-Anordnungen (FPGA, field programmable gate arrays) oder programmierbare Logikanordnungen (PLA, programmable logic arrays) die durch einen Computer lesbaren Programmanweisungen ausführen, indem sie Zustandsinformationen der durch einen Computer lesbaren Programmanweisungen nutzen, um die elektronischen Schaltungen zu personalisieren, um Aspekte der vorliegenden Erfindung durchzuführen.
Aspekte der vorliegenden Erfindung sind hierin unter Bezugnahme auf Ablaufpläne und/oder Blockschaltbilder bzw. Schaubilder von Verfahren, Vorrichtungen (Systemen) und Computerprogrammprodukten gemäß Ausführungsformen der Erfindung beschrieben. Es wird darauf hingewiesen, dass jeder Block der Ablaufpläne und/oder der Blockschaltbilder bzw. Schaubilder sowie Kombinationen von Blöcken in den Ablaufplänen und/oder den Blockschaltbildern bzw. Schaubildern mittels durch einen Computer lesbare Programmanweisungen ausgeführt werden können.
Diese durch einen Computer lesbaren Programmanweisungen können einem Prozessor eines Universalcomputers, eines Spezialcomputers oder einer anderen programmierbaren Datenverarbeitungsvorrichtung bereitgestellt werden, um eine Maschine zu erzeugen, so dass die über den Prozessor des Computers bzw. der anderen programmierbaren Datenverarbeitungsvorrichtung ausgeführten Anweisungen ein Mittel zur Umsetzung der in dem Block bzw. den Blöcken der Ablaufpläne und/oder der Blockschaltbilder bzw. Schaubilder festgelegten Funktionen/Schritte erzeugen. Diese durch einen Computer lesbaren Programmanweisungen können auch auf einem durch einen Computer lesbaren Speichermedium gespeichert sein, das einen Computer, eine programmierbare Datenverarbeitungsvorrichtung und/oder andere Einheiten so steuern kann, dass sie auf eine bestimmte Art funktionieren, so dass das durch einen Computer lesbare Speichermedium, auf dem Anweisungen gespeichert sind, ein Herstellungsprodukt aufweist, darunter Anweisungen, welche Aspekte der/des in dem Block bzw. den Blöcken des Ablaufplans und/oder der Blockschaltbilder bzw. Schaubilder angegebenen Funktion/Schritts umsetzen.
Die durch einen Computer lesbaren Programmanweisungen können auch auf einen Computer, eine andere programmierbare Datenverarbeitungsvorrichtung oder eine andere Einheit geladen werden, um das Ausführen einer Reihe von Prozessschritten auf dem Computer bzw. der anderen programmierbaren Vorrichtung oder anderen Einheit zu verursachen, um einen auf einem Computer ausgeführten Prozess zu erzeugen, so dass die auf dem Computer, einer anderen programmierbaren Vorrichtung oder einer anderen Einheit ausgeführten Anweisungen die in dem Block bzw. den Blöcken der Ablaufpläne und/oder der Blockschaltbilder bzw. Schaubilder festgelegten Funktionen/Schritte umsetzen.
Die Ablaufpläne und die Blockschaltbilder bzw. Schaubilder in den Figuren veranschaulichen die Architektur, die Funktionalität und den Betrieb möglicher Ausführungen von Systemen, Verfahren und Computerprogrammprodukten gemäß verschiedenen Ausführungsformen der vorliegenden Erfindung. In diesem Zusammenhang kann jeder Block in den Ablaufplänen oder Blockschaltbildern bzw. Schaubildern ein Modul, ein Segment oder einen Teil von Anweisungen darstellen, die eine oder mehrere ausführbare Anweisungen zur Ausführung der bestimmten logischen Funktion(en) aufweisen. In einigen alternativen Ausführungen können die in dem Block angegebenen Funktionen in einer anderen Reihenfolge als in den Figuren gezeigt stattfinden. Zwei nacheinander gezeigte Blöcke können zum Beispiel in Wirklichkeit im Wesentlichen gleichzeitig ausgeführt werden, oder die Blöcke können manchmal je nach entsprechender Funktionalität in umgekehrter Reihenfolge ausgeführt werden. Es ist ferner anzumerken, dass jeder Block der Blockschaltbilder bzw. Schaubilder und/oder der Ablaufpläne sowie Kombinationen aus Blöcken in den Blockschaltbildern bzw. Schaubildern und/oder den Ablaufplänen durch spezielle auf Hardware beruhende Systeme umgesetzt werden können, welche die festgelegten Funktionen oder Schritte durchführen, oder Kombinationen aus Spezial-Hardware und Computeranweisungen ausführen.
ZITATE ENTHALTEN IN DER BESCHREIBUNG
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
Zitierte Patentliteratur

US 15625223 [0089, 0105]

Claims

Virtuelles Cacheverzeichnis in einem Prozessor mit Unterstützung virtuellen Speichers, wobei das virtuelle Cacheverzeichnis eine Mehrzahl von Verzeichniseinträgen besitzt, wobei jeder Eintrag einer Cachezeile zugeordnet ist, aufweisend: ein jedem der Mehrzahl von Verzeichniseinträgen zugeordnetes Tag, wobei das Tag aufweist: eine logische Adresse; eine Adressraumkennung; einen Bitanzeiger einer realen Adresse; und einen Anzeiger von virtueller Adresse zu realer Adresse.
Virtuelles Cacheverzeichnis nach Anspruch 1, wobei der Anzeiger von virtueller Adresse zu realer Adresse ein einzelnes Bit ist.
Virtuelles Cacheverzeichnis nach Anspruch 1, wobei der Anzeiger von virtueller Adresse zu realer Adresse gesetzt ist, wenn die logische Adresse dieselbe wie die reale Adresse ist.
Virtuelles Cacheverzeichnis nach Anspruch 1, wobei, wenn der Anzeiger von virtueller Adresse zu realer Adresse gesetzt ist, keine dynamische Adressübersetzung durchgeführt wird.
Virtuelles Cacheverzeichnis nach Anspruch 1, wobei der Anzeiger von virtueller Adresse zu realer Adresse bei jedem Nachschlagen in einem Translation Lookaside Buffer neu berechnet wird.
Verfahren zum Betreiben eines Prozessorcache für einen Prozessor mit Unterstützung von virtuellem Speicher, wobei ein logisch indexiertes und logisch getagtes Cacheverzeichnis verwendet wird, und wobei ein Eintrag im Verzeichnis eine absolute Speicheradresse zusätzlich zur entsprechenden logischen Speicheradresse und ein Flag von virtuell zu real enthält, aufweisend: ein Speichern von Code in eine logische Speicheradresse in einem ersten Eintrag in dem Cacheverzeichnis; ein Aufrufen, durch Benutzercode, eines zugrundeliegenden Betriebssystems; ein Lesen durch das Betriebssystem des Codes aus der absoluten Speicheradresse; ein Ausführen eines Transload auf dem ersten Eintrag; ein Ermitteln, ob die absolute Speicheradresse gleich der logischen Speicheradresse ist; und als Reaktion auf ein Feststellen, dass die absolute Speicheradresse gleich der logischen Speicheradresse ist, ein Setzen des Flag von virtuell zu real auf Ein.
Verfahren nach Anspruch 6, wobei der Benutzercode auf das zugrundeliegende Betriebssystem durch einen Hypervisor zugreift.
Verfahren nach Anspruch 6, wobei das Speichern von Code einen Verzeichniseintrag im Cache für den Eintrag erzeugt, dessen Flag für dynamische Adressübersetzung auf Ein und dessen Real-Bit-Flag auf Aus gesetzt ist.
Verfahren nach Anspruch 8, wobei das Ausführen eines Transload das Flag für dynamische Adressübersetzung auf Aus und das Real-Bit-Flag auf Ein schaltet.
Verfahren nach Anspruch 8, wobei, wenn das Flag von virtuell zu real auf Ein gesetzt ist, ein Flag eines Status der dynamischen Adressübersetzungen ignoriert wird.
Verfahren nach Anspruch 6, wobei ein Translation Lookaside Buffer konfiguriert ist, Informationen bezüglich des Flag von virtuell zu real zurückzugeben.
Verfahren nach Anspruch 11, wobei für jedes Nachschlagen im Translation Lookaside Buffer das Flag von virtuell zu real neu berechnet wird.
Computerprogrammprodukt mit computerausführbaren Anweisungen zum Betreiben eines Prozessors mit Unterstützung von virtuellem Speicher, wobei ein logisch indexiertes und logisch getagtes Cacheverzeichnis verwendet wird, und wobei ein Eintrag im Verzeichnis eine absolute Speicheradresse zusätzlich zu einer entsprechenden logischen Speicheradresse und ein Flag von virtuell zu real enthält, das bei Ausführen mindestens einen Computer veranlasst, ein Verfahren auszuführen, aufweisend: ein Speichern von Code in eine logische Speicheradresse in einem ersten Eintrag in dem Cacheverzeichnis; ein Aufrufen, durch Benutzercode, eines zugrundeliegenden Betriebssystems; ein Lesen durch das Betriebssystem des Codes aus der absoluten Speicheradresse; ein Ausführen eines Transload auf dem ersten Eintrag; ein Ermitteln, ob die absolute Speicheradresse gleich der logischen Speicheradresse ist; und als Reaktion auf ein Feststellen, dass die absolute Speicheradresse gleich der logischen Speicheradresse ist, ein Setzen des Flag von virtuell zu real auf Ein.
Computerprogrammprodukt nach Anspruch 13, wobei der Benutzercode auf das zugrundeliegende Betriebssystem durch einen Hypervisor zugreift.
Computerprogrammprodukt nach Anspruch 13, wobei das Speichern von Code einen Verzeichniseintrag im Cache für den Eintrag erzeugt, dessen Flag für dynamische Adressübersetzung auf Ein und dessen Real-Bit-Flag auf Aus gesetzt ist.
Computerprogrammprodukt nach Anspruch 15, wobei das Ausführen eines Transload das Flag für dynamische Adressübersetzung auf Aus und das Real-Bit-Flag auf Ein schaltet.
Computerprogrammprodukt nach Anspruch 15, wobei, wenn das Flag von virtuell zu real auf Ein gesetzt ist, ein Flag eines Status der dynamischen Adressübersetzungen ignoriert wird.
Computerprogrammprodukt nach Anspruch 13, wobei ein Translation Lookaside Buffer konfiguriert ist, Informationen bezüglich des Flag von virtuell zu real zurückzugeben.
Computerprogrammprodukt nach Anspruch 18, wobei für jedes Nachschlagen im Translation Lookaside Buffer das Flag von virtuell zu real neu berechnet wird.