DE112018002028T5 - Umsetzungsunterstützung für einen virtuellen cache - Google Patents

Umsetzungsunterstützung für einen virtuellen cache Download PDF

Info

Publication number
DE112018002028T5
DE112018002028T5 DE112018002028.2T DE112018002028T DE112018002028T5 DE 112018002028 T5 DE112018002028 T5 DE 112018002028T5 DE 112018002028 T DE112018002028 T DE 112018002028T DE 112018002028 T5 DE112018002028 T5 DE 112018002028T5
Authority
DE
Germany
Prior art keywords
cache
directory
entry
address
thread
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
DE112018002028.2T
Other languages
English (en)
Inventor
Martin Recktenwald
Anthony Saporito
Christian Jacobi
Aaron Tsai
Johannes Christian Reichart
Markus Michael Helms
Ulrich Mayer
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
International Business Machines Corp
Original Assignee
International Business Machines Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by International Business Machines Corp filed Critical International Business Machines Corp
Publication of DE112018002028T5 publication Critical patent/DE112018002028T5/de
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02—Addressing or allocation; Relocation
    • G06F12/08—Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
    • G06F12/0802—Addressing of a memory level in which the access to the desired data or data block requires associative addressing means, e.g. caches
    • G06F12/0806—Multiuser, multiprocessor or multiprocessing cache systems
    • G06F12/0808—Multiuser, multiprocessor or multiprocessing cache systems with cache invalidating means
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02—Addressing or allocation; Relocation
    • G06F12/08—Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
    • G06F12/0802—Addressing of a memory level in which the access to the desired data or data block requires associative addressing means, e.g. caches
    • G06F12/0806—Multiuser, multiprocessor or multiprocessing cache systems
    • G06F12/0815—Cache consistency protocols
    • G06F12/0817—Cache consistency protocols using directory methods
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02—Addressing or allocation; Relocation
    • G06F12/08—Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
    • G06F12/0802—Addressing of a memory level in which the access to the desired data or data block requires associative addressing means, e.g. caches
    • G06F12/0806—Multiuser, multiprocessor or multiprocessing cache systems
    • G06F12/0842—Multiuser, multiprocessor or multiprocessing cache systems for multiprocessing or multitasking
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02—Addressing or allocation; Relocation
    • G06F12/08—Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
    • G06F12/0802—Addressing of a memory level in which the access to the desired data or data block requires associative addressing means, e.g. caches
    • G06F12/0864—Addressing of a memory level in which the access to the desired data or data block requires associative addressing means, e.g. caches using pseudo-associative means, e.g. set-associative or hashing
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02—Addressing or allocation; Relocation
    • G06F12/08—Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
    • G06F12/10—Address translation
    • G06F12/1009—Address translation using page tables, e.g. page table structures
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02—Addressing or allocation; Relocation
    • G06F12/08—Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
    • G06F12/10—Address translation
    • G06F12/1027—Address translation using associative or pseudo-associative address translation means, e.g. translation look-aside buffer [TLB]
    • G06F12/1045—Address translation using associative or pseudo-associative address translation means, e.g. translation look-aside buffer [TLB] associated with a data cache
    • G06F12/1063—Address translation using associative or pseudo-associative address translation means, e.g. translation look-aside buffer [TLB] associated with a data cache the data cache being concurrently virtually addressed
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02—Addressing or allocation; Relocation
    • G06F12/08—Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
    • G06F12/0802—Addressing of a memory level in which the access to the desired data or data block requires associative addressing means, e.g. caches
    • G06F12/0806—Multiuser, multiprocessor or multiprocessing cache systems
    • G06F12/0811—Multiuser, multiprocessor or multiprocessing cache systems with multilevel cache hierarchies
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02—Addressing or allocation; Relocation
    • G06F12/08—Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
    • G06F12/0802—Addressing of a memory level in which the access to the desired data or data block requires associative addressing means, e.g. caches
    • G06F12/0893—Caches characterised by their organisation or structure
    • G06F12/0897—Caches characterised by their organisation or structure with two or more cache hierarchy levels
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
    • G06F2212/10—Providing a specific technical effect
    • G06F2212/1016—Performance improvement
    • G06F2212/1021—Hit rate improvement
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
    • G06F2212/10—Providing a specific technical effect
    • G06F2212/1028—Power efficiency
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
    • G06F2212/28—Using a specific disk cache architecture
    • G06F2212/283—Plural cache memories
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
    • G06F2212/62—Details of cache specific to multiprocessor cache arrangements
    • G06F2212/621—Coherency control relating to peripheral accessing, e.g. from DMA or I/O device
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
    • G06F2212/65—Details of virtual memory and virtual address translation
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
    • G06F2212/65—Details of virtual memory and virtual address translation
    • G06F2212/656—Address space sharing
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
    • G06F2212/68—Details of translation look-aside buffer [TLB]
    • G06F2212/683—Invalidation
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management

Abstract

Offenbart hierin ist ein virtueller Cache und ein Verfahren in einem Prozessor zur Unterstützung von mehreren Threads auf derselben Cachezeile. Der Prozessor ist so konfiguriert, dass er einen virtuellen Speicher und mehrere Threads unterstützt. Das virtuelle Cacheverzeichnis enthält eine Vielzahl von Verzeichniseinträgen, wobei jeder Eintrag zu einer Cachezeile gehört. Jede Cachezeile hat ein entsprechendes Tag. Das Tag enthält eine logische Adresse, eine Adressraumkennung, einen Bitanzeiger für eine reale Adresse und ein threadweises Gültigkeitsbit für jeden Thread, der auf die Cachezeile zugreift. Wenn ein nachfolgender Thread feststellt, dass die Cachezeile für diesen Thread gültig ist, wird das Gültigkeitsbit für diesen Thread gesetzt, während beliebige Gültigkeitsbits für andere Threads nicht ungültig gemacht werden.

Description

  • HINTERGRUND
  • Die vorliegende Offenbarung betrifft das Gebiet der digitalen Computersysteme und insbesondere ein Verfahren zum Steuern des Zugriffs auf einen Cachespeicher.
  • Neueste Mikroprozessor-Architektur gestattet es Software, so genannte „virtuelle“ (oder zuweilen als „logische“ Adressen bezeichnete) Adressen zu verwenden, um Speicherpositionen zu referenzieren. Der Speicherzugriff selbst erfolgt unter Verwendung einer „physischen“ (oder zuweilen als „absolut“ bezeichneten) Adresse. Für eine Umsetzung zwischen den beiden wird üblicherweise eine Datenstruktur mit der Bezeichnung „Adressumsetzpufferspeicher“ (TLB, Translation Lookaside Buffer) verwendet. Der Prozess der Umsetzung wird zuweilen als Dynamische Adressumsetzung (DAT, Dynamic Address Translation), insbesondere bei der z/Architecture von IBM, bezeichnet.
  • In einem typischen Mikroprozessorsystem werden mehrere Stufen von Caches verwendet, um Speicherzugriffe zu beschleunigen, indem eine Kopie des Speicherinhalts „nahe“ am Prozessorkern aufbewahrt wird. Bei Cache-Ausführungen, die DAT unterstützen, indexiert eine häufig verwendete Ausführung in das Cacheverzeichnis unter Verwendung eines Teils der logischen Adresse, und die so genannten „Tag“-Informationen, mit denen die Suchanforderung verglichen wird, verwendet absolute Adressen. Dies macht eine Umsetzung der logischen Adresse, die von dem Programm verwendet wird, in eine absolute Adresse erforderlich, was gewöhnlich eine Suche in dem TLB einschließt.
  • Mit immer größer werdenden Mikroprozessorkern-Caches müssen jedoch auch TLBs größer werden, und der Stromverbrauch der TLB-Suche zusätzlich zu der Verzeichnissuche trägt erheblich zur Leistung des Mikroprozessorkerns bei. Auch ist die Größe des TLBs durch Zeitbindungen beschränkt, da die TLB-Suche selbst ein Teil des kritischen Pfades wird.
  • Ein „virtueller Cache“ speichert Umsetzungsinformationen im Cacheverzeichnis anstatt in einem TLB. Dies spart den Strom und die Latenzzeit, die bei der TLB-Suche eine Rolle spielen. Bei einem Entwurf eines nicht virtuellen Caches kann dieselbe Cachezeile jedoch von verschiedenen Umsetzungen gleichzeitig „verwendet“ werden. Dies ist möglich, weil diese verschiedenen Umsetzungen von logisch in absolut in einem TLB gleichzeitig vorhanden sein können. In dem virtuellen Cache können nur die in dem Cacheverzeichnis gespeicherten Umsetzungsinformationen verwendet werden.
  • Ein wichtiger Fall, bei dem mehrere verschiedene Umsetzungen in dieselbe absolute Adresse parallel verwendet werden, betrifft das Multithreading: Software, die auf verschiedenen Threads auf demselben Kern ausgeführt wird, kann Speicher anteilig mitbenutzen, selbst wenn die CPU-Architektur (wie beispielsweise die z/Architecture) TLB-Einträge als nicht zwischen Threads gemeinsam nutzbar definiert. Somit können mehrere Threads dieselben Adressumsetzungen verwenden, jedoch haben sie unterschiedliche TLB-Einträge. Gemeinsam genutzte Bibliotheken können die Sache noch komplizierter machen, da sie oftmals eine andere Umsetzung für verschiedene Threads verwenden.
  • KURZDARSTELLUNG
  • Verschiedene Ausführungsformen stellen ein Verfahren zum Steuern des Zugriffs auf einen Cachespeicher, eine Vorrichtung und ein Computerprogrammprodukt bereit, wie durch den Gegenstand der unabhängigen Ansprüche beschrieben ist. Vorteilhafte Ausführungsformen sind in den abhängigen Ansprüchen beschrieben. Ausführungsformen der vorliegenden Erfindung können frei miteinander kombiniert werden, sofern sie sich nicht gegenseitig ausschließen.
  • Eine einzelne Ausführungsform ist auf ein virtuelles Cacheverzeichnis in einem Prozessor gerichtet. Der Prozessor ist so konfiguriert, dass er virtuellen Speicher und mehrere Threads unterstützt. Das virtuelle Cacheverzeichnis enthält eine Vielzahl von Verzeichniseinträgen, wobei jeder Eintrag zu einer Cachezeile gehört. Jede Cachezeile hat ein Tag. Das Tag enthält eine logische Adresse, eine Adressraumkennung, einen Bitanzeiger für eine reale Adresse und ein threadweises Gültigkeitsbit für jeden Thread, der auf die Cachezeile zugreift.
  • Eine einzelne Ausführungsform ist auf ein Verfahren zum Betreiben eines primären Prozessor-Caches für einen Prozessor mit Unterstützung eines virtuellen Speichers und mehrerer Threads gerichtet. Der Prozessor verwendet ein logisch indexiertes und logisch getaggtes Cacheverzeichnis, und ein Eintrag in dem Verzeichnis enthält eine absolute Speicheradresse zusätzlich zu einer entsprechenden logischen Speicheradresse. Jeder Eintrag enthält ein Gültig-Bit für jeden Thread, der auf jeden Eintrag zugreift. Das Verfahren stellt durch einen ersten Thread fest, dass eine Cachezeile nicht in dem primären Cache vorhanden ist. Als Nächstes wird festgestellt, dass sich die Cachezeile in einem sekundären Cache befindet. Als Reaktion auf die Feststellung, dass sich die Cachezeile in dem sekundären Cache befindet, wird ein neuer Eintrag für die Cachezeile in dem primären Cache erstellt. Als Nächstes wird durch einen zweiten Thread festgestellt, dass ein Eintrag für die Cachezeile in dem primären Cache vorhanden ist. Als Reaktion auf die Feststellung, dass der Eintrag für die Cachezeile in dem primären Cache vorhanden ist, wird festgestellt, dass die Cachezeile für den zweiten Thread nicht gültig ist. Im Anschluss an die Feststellung wird eine Suche ausgeführt, um eine Adresse für die Cachezeile in dem primären Cache festzustellen. Dann wird festgestellt, dass es sich bei der Adresse für die Cachezeile und dem Eintrag um dieselbe Cachezeile handelt. Als Reaktion auf die Feststellung, dass die Adresse und der Eintrag identisch sind, wird das zu dem zweiten Thread gehörende Gültig-Bit auf gültig gesetzt und das zu anderen Threads in dem Cacheeintrag gehörende Gültig-Bit wird nicht ungültig gemacht.
  • Figurenliste
  • Im Folgenden werden Ausführungsformen der Erfindung lediglich beispielhalber unter Bezugnahme auf die Zeichnungen ausführlicher erklärt, bei denen:
    • 1 ein Computersystem gemäß einem Beispiel der vorliegenden Offenbarung veranschaulicht;
    • 2 ein Blockschaubild ist, das ein Schaubild für den Zugriff auf eine Cachestruktur eines Cachespeichers mit einem zweistufigen Cache 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 des Zugriffs auf einen Cachespeicher ist;
    • 6 eine schematische Darstellung eines Tags gemäß Ausführungsformen ist;
    • 7 ein Ablaufplan ist, der einen Prozess der Datenübertragung durch einen gemeinsam genutzten Speicher veranschaulicht;
    • 8 ein Ablaufplan ist, der die Erweiterung von virtuell in real in den Cache gemäß Ausführungsformen veranschaulicht;
    • 9 eine schematische Darstellung eines Verzeichnisvergleichs unter Verwendung der Erweiterung gemäß Ausführungsformen ist;
    • 10 eine schematische Darstellung eines Tags gemäß Ausführungsformen ist;
    • 11 ein Ablaufplan ist, der einen Prozess für den Zugriff auf eine Cachezeile durch einen ersten Thread gemäß Ausführungsformen veranschaulicht;
    • 12 ein Ablaufplan ist, der einen Prozess für den Zugriff auf eine gemeinsam genutzte Cachezeile durch einen zweiten Thread gemäß Ausführungsformen veranschaulicht;
    • 13 ein Entscheidungsbaum ist, der den Prozess von 11 und 12 in Kombination gemäß Ausführungsformen veranschaulicht;
    • 14 ein Ablaufplan ist, der das Auflösen eines L1-Cachefehlers gemäß Ausführungsformen veranschaulicht;
    • 15 eine schematische Darstellung der gemeinsamen Nutzung eines Caches für Threads ist, die verschiedene Umsetzungen verwenden;
    • 16 eine schematische Darstellung der gemeinsamen Nutzung von Teilen eines Verzeichniseintrags gemäß Ausführungsformen ist;
    • 17 ein Entscheidungsbaum ist, der den Prozess der gemeinsamen Nutzung von Verzeichniseinträgen durch Teil-Threads gemäß Ausführungsformen ausführt.
  • AUSFÜHRLICHE BESCHREIBUNG
  • Die Beschreibungen der verschiedenen Ausführungsformen der vorliegenden Erfindung erfolgen zum Zweck der Veranschaulichung, sollen jedoch nicht erschöpfend oder auf die offenbarten Ausführungsformen beschränkt sein. Viele Modifikationen und Varianten sind für den Fachmann erkennbar, ohne vom Umfang und Wesen 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 befindlicher Technologien am besten zu erklären bzw. um anderen Fachleuten das Verständnis zu ermöglichen.
  • Der Cachespeicher ist ein satzassoziativer Cache.
  • Das vorliegende Verfahren verwendet ein logisch indexiertes, logisch getaggtes Verzeichnis, das alle umsetzungsrelevanten Informationen in dem L1-Cache speichert. Um so viel Strom wie möglich zu sparen, verwendet das vorliegende Verfahren ein Satzverzeichnis, um den möglichen Treffersatz für die anderen L1-Cachestrukturen auszuwählen. Das Satzverzeichnis wird als Cache Array Late Select verwendet und kann daher verglichen mit einem herkömmlichen Entwurf nicht zum Strom- und Flächenbudget beitragen. Bei Verwendung des Satzverzeichnisses, um zusätzlichen Strom zu sparen, wird anstelle einer herkömmlichen satzassoziativen Verzeichnisstruktur ein „vertikal gestapeltes“ Verzeichnis (d.h. das Validierungsverzeichnis) verwendet. Folglich kann immer nur ein Satz auf einmal ausgelesen werden, während nach dem Stand der Technik alle Sätze, die zu einem bestimmten Index gehören, parallel gelesen werden konnten. Da das Cacheverzeichnis zum Beispiel verwendet werden kann, um Probleme mit Synonymen zu lösen, muss auf die Validierungsverzeichnissätze gegebenenfalls nicht parallel zugegriffen werden.
  • Das vorliegende Verfahren kann den Vorteil haben, dass es einen verbesserten satzassoziativen Cachespeicher mit schneller Zugriffszeit und dennoch geringem Stromverbrauch im Vergleich zu Verfahren nach dem Stand der Technik, bei denen ein L1-Cachetreffer eine Validierung von einem höherstufigen Cache erfordert, bereitstellt.
  • Aufgrund seiner verhältnismäßig großen Größe kann der TLB gewöhnlich nicht in unmittelbarer Nähe zum Speicherbereich angeordnet werden. Folglich nimmt die gesamte Cachezugriffszeit eines satzassoziativen Cachespeichers mit der Größe seines TLBs und der Größe seiner Speicherbereiche zu. Das vorliegende Verfahren verwendet ein logisch getaggtes und logisch indexiertes Validierungsverzeichnis und kann somit die Notwendigkeit, einen TLB für die Erzeugung eines L1-Cache-Treffersignals einschalten zu müssen, vermeiden.
  • Gemäß einer einzelnen Ausführungsform wird ein Fehlersignal erzeugt, falls der zweite Suchlauf das Vorhandensein der Cachezeile in dem Satz nicht bestätigt. Das Fehlersignal ist ein Cachefehlersignal, das einen Cachefehler für die angeforderte effektive Adresse (die auch als logische oder virtuelle Adresse bezeichnet wird) anzeigt. Das Cachefehlersignal kann auch erzeugt werden, falls der erste Suchlauf die angeforderte logische Adresse in dem Satzverzeichnis nicht findet. Als Reaktion auf das erzeugte Fehlersignal kann die angeforderte Cachezeile in einer höheren Cachestufe oder im Hauptspeicher (z.B. RAM) gesucht werden.
  • Gemäß einer einzelnen Ausführungsform weist der Cachespeicher des Weiteren einen Adressumsetzpufferspeicher, TLB, auf, wobei ein bestimmter Eintrag in dem primären Cacheverzeichnis ein Gültig-Bit, einen Teil der effektiven Adresse und einen Satzindex speichert, wobei, falls der zweite Suchlauf das Vorhandensein der Cachezeile in dem Satz nicht bestätigt, das Verfahren des Weiteren aufweist: Suchen der Zeilenindexbits in dem primären Cacheverzeichnis, was zu einem logischen Zeiger für jeden Satz in dem primären Cacheverzeichnis führt, wobei der logische Zeiger den Satzindex und den Teil der effektiven Adresse aufweist; Auswählen eines logischen Zeigers der logischen Zeiger, dessen Satzindex mit der Satzkennung übereinstimmt; Suchen der effektiven Adresse in dem TLB, um eine absolute Adresse zu kennzeichnen, die zu der effektiven Adresse gehört; Suchen der effektiven Adresse in einem höherstufigen sekundären Cacheverzeichnis des Cachespeichers, um einen Eintrag zu erhalten, der der effektiven Adresse in jedem Satz in dem sekundären Cacheverzeichnis entspricht, wobei der Eintrag eine weitere absolute Adresse aufweist; Vergleichen einer jeden erhaltenen absoluten Adresse des sekundären Cacheverzeichnisses mit der absoluten Adresse des TLBs, 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 über die andere Satzkennung mit dem ausgewählten logischen Zeiger verfügt, und beruhend auf den Vergleichsergebnissen Bestätigen des Fehlersignals oder Aktualisieren des Satzes und der Validierungsverzeichnisse.
  • Der TLB und der höherstufige Cache werden zum Beispiel im Falle eines Cachefehlers in dem Cache der niedrigeren Stufe verwendet. Dies kann eine zuverlässige Validierung oder Bestätigung des Cachefehlers auf der niedrigeren Cachestufe bereitstellen.
  • Gemäß einer einzelnen Ausführungsform wird das Durchsuchen des primären Cacheverzeichnisses parallel zu dem ersten Suchlauf durchgeführt. Diese Ausführungsform kann den Zugriff auf Daten weiter beschleunigen.
  • Gemäß einer einzelnen Ausführungsform weist das Verfahren des Weiteren auf: das Erzeugen des Treffersignals wird durchgeführt, wenn das Gültig-Bit des logischen Zeigers auf einen gültigen Zustand gesetzt ist. Das Gültig-Bit ist ein Informationsbit, das anzeigt, ob die Daten in einer Cachezeile gültig sind oder nicht. Dies kann weiter Verarbeitungszeit sparen, die andernfalls für den Zugriff auf ungültig gemachte Daten und für Korrekturen, die durch die Verarbeitung verursacht werden, benötigt würde.
  • Gemäß einer einzelnen Ausführungsform wird die Suche in dem TLB und die Suche in dem sekundären Cacheverzeichnis parallel durchgeführt. Diese Ausführungsform kann den Zugriff auf Daten weiter beschleunigen.
  • Gemäß einer einzelnen Ausführungsform sind die erste Gruppe von Bits die niedrigstwertigen Bits aus dem Tag-Feld und die zweite Gruppe von Bits sind die höchstwertigen Bits aus dem Tag-Feld. Die zweite Gruppe von Bits kann ergänzend zu der ersten Gruppe von Bits sein, um die Suchergebnisse des Satzverzeichnisses zu bestätigen. Wenn die effektive Adresse zum Beispiel ein Tag-Feld von 0:49 Bits hat, kann die erste Gruppe von Bits 37:49 und die zweite Gruppe von Bits kann 0:36 sein. Jedoch kann ein beliebiges Subset des Tag-Feldes 0:49 als die erste oder die zweite Gruppe von Bits verwendet werden. Die Breite der ersten Gruppe von Bits (d.h. die Anzahl der Bits) kann auf einem Kompromiss zwischen einer falschen Vorhersage (nicht zu klein) und Zeitbindungen (keine zu großen Vergleiche) sein. Das Verwenden der Bits neben dem Zeilenindex (50:55) der effektiven Adresse für die erste Gruppe kann vorteilhaft sein, da dies auch bei Programmen mit geringem Speicherbedarf 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-Wege-Assoziativität (z.B. n=8) zu verwenden, da nur sehr große Programme effektive Adressen haben können, die sich bei 0:12 unterscheiden, so dass Programme normaler Größe nur einen Satz verwenden könnten. Anders ausgedrückt, die Bits der ersten Gruppe (z.B. 37:49) werden so gewählt, dass sie sich bei den meisten Speicherzugriffen unterscheiden und noch nicht mit dem Zeilenindex überlappen.
  • Gemäß einer einzelnen Ausführungsform wird das Validierungsverzeichnis aus einer physischen Array-Struktur erstellt, die einen Verzeichniseintrag für jede Cachezeile von allen Sätzen des Cachespeichers hält. Diese Ausführungsform kann es ermöglichen, dass nur ein Satz auf einmal ausgelesen werden kann, während nach dem Stand der Technik alle Sätze, die zu einem bestimmten Index gehören, parallel gelesen werden konnten. Diese Ausführungsform kann den Zugriff auf Daten somit weiter beschleunigen. Zum Beispiel kann das Ergebnis des Satzverzeichnisses (z.B. eine Satzkennung) als Erweiterung des Zeilenindexes (z.B. der Bits 50:55) verwendet werden, um das Validierungsverzeichnis zu durchsuchen.
  • Gemäß einer einzelnen Ausführungsform speichert ein bestimmter Eintrag in dem primären Cacheverzeichnis ein Gültig-Bit, einen Teil der effektiven Adresse und einen Satzindex, wobei das Verfahren des Weiteren aufweist: parallel zu dem ersten Suchlauf Suchen der Zeilenindexbits in dem primären Cacheverzeichnis, was zu einem Wert des Gültig-Bits für jeden Satz in dem primären Cacheverzeichnis führt, Auswählen eines Werts des Gültig-Bits von den Werten des Gültig-Bits, dessen zugehöriger Satzindex mit der Satzkennung übereinstimmt, wobei das Erzeugen des Treffersignals durchgeführt wird, wenn der Wert des Gültig-Bits einen gültigen Zustand anzeigt. Dies kann weiter Verarbeitungszeit sparen, die andernfalls für den Zugriff auf ungültig gemachte Daten und für Korrekturen, die durch die Verarbeitung verursacht werden, benötigt würde.
  • Gemäß einer einzelnen Ausführungsform ist das primäre Cacheverzeichnis ein Cacheverzeichnis der Stufe L1. Gemäß einer einzelnen Ausführungsform ist das sekundäre Cacheverzeichnis ein Cacheverzeichnis der Stufe L2. Diese Ausführungsformen können nahtlos in vorhandene Systeme integriert werden.
  • Gemäß einer einzelnen Ausführungsform ist der Cachespeicher ein mehrstufiges Cacheverzeichnis, das des Weiteren ein sekundäres Cacheverzeichnis aufweist. Der Cachespeicher ist ein satzselektiver Speicher.
  • Gemäß einer einzelnen Ausführungsform speichert ein bestimmter Eintrag in dem primären Cacheverzeichnis ein Gültig-Bit, einen Teil der effektiven Adresse und einen Satzindex. Das Verfahren weist des Weiteren auf: Empfangen eines Synonyms für die zweite effektive Adresse der effektiven Adresse; Wiederholen des ersten und des zweiten Suchlaufs unter Verwendung der zweiten effektiven Adresse; falls der zweite Suchlauf das Vorhandensein der Cachezeile, auf die die zweite effektive Adresse verweist, nicht bestätigt, Ungültigmachen des Eintrags des Satzverzeichnisses, der der zweiten effektiven Adresse entspricht; Durchführen des ersten Suchlaufs unter Verwendung der zweiten effektiven Adresse, um einen Fehler zu erkennen; Suchen der zweiten effektiven Adresse in dem primären Cacheverzeichnis, was zu einem logischen Zeiger für jeden Satz in dem primären Cacheverzeichnis führt, wobei der logische Zeiger den Satzindex und den Teil der zweiten effektiven Adresse aufweist; Suchen der zweiten effektiven Adresse in einem höherstufigen sekundären Verzeichniscache des Cachespeichers, um einen Eintrag zu erhalten, der der zweiten effektiven Adresse in jedem Satz in dem sekundären Cacheverzeichnis entspricht; Vergleichen der logischen Adresse des Eintrags des Satzes des sekundären Cacheverzeichnisses mit jedem der logischen Zeiger und beruhend auf den Vergleichsergebnissen Bestätigen des Vorhandenseins der Cachezeile in dem primären Cacheverzeichnis; Aktualisieren des Satzes und der Validierungsverzeichnisse, indem Einträge in Bezug auf die effektive Adresse mit der zweiten effektiven Adresse überschrieben werden; Wiederholen des ersten Suchlaufs, des zweiten Suchlaufs und Erzeugen des bedingten Treffersignals. Diese Ausführungsform kann den Vorteil haben, dass sie Probleme mit Synonymen an dem Cachespeicher wirksam löst. Sie löst Probleme mit Synonymen, indem sie sich auf den/die Cache(s) der nächsten Stufe verlässt. Sie verwendet das L1-Cacheverzeichnis, um den L1-Cache und den L2-Cache miteinander zu verknüpfen.
  • 1 veranschaulicht ein Computersystem 100 gemäß einem Beispiel der vorliegenden Offenbarung. Das Computersystem 100 kann auf der von der 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, darunter den Eingabe-/Ausgabe-(E/A-)Einheiten 104 (wie beispielsweise einem Bildschirmmonitor, einer Tastatur und einer permanenten Massenspeichereinheit), der Speichereinheit 106 (wie beispielsweise einem Direktzugriffsspeicher oder RAM), die von den Verarbeitungseinheiten zur Ausführung von Programmanweisungen verwendet wird, sowie Firmware 108, deren primärer Zweck darin besteht, immer dann nach einem Betriebssystem zu suchen und es aus einem der Peripheriegeräte zu laden, wenn der Computer erstmalig eingeschaltet wird. Die Verarbeitungseinheit 101 tauscht mit den Peripherieeinheiten (z.B. der Firmware 118, den E/A-Einheiten 114 und dem Speicher 116) über verschiedene Mittel, darunter eine allgemeine Verbindung oder einen Bus 120, Daten aus.
  • Die Verarbeitungseinheit 101 enthält einen Prozessorkern 122, der über eine Vielzahl von Registern und Ausführungseinheiten verfügt, die Programmanweisungen ausführen, um den Computer zu betreiben. Zu einer beispielhaften Verarbeitungseinheit gehört der von der International Business Machines Corporation vertriebene Prozessor PowerPC™. Die Verarbeitungseinheit 101 kann auch einen oder mehrere Caches haben. Zum Beispiel ist die Verarbeitungseinheit 101 als zwei Caches126 und 130 aufweisend gezeigt. Caches werden verwendet, um Werte vorübergehend zu speichern, auf die ein Prozessor wiederholt zugreifen könnte, um die Verarbeitung zu beschleunigen, indem der längere Schritt des Ladens der Werte aus dem Speicher 116 vermieden wird.
  • Bei den Caches 126 und 130 handelt es sich um satzassoziative Caches, die es einem Prozessor ermöglichen, eine verhältnismäßig schnelle Zugriffszeit auf ein Subset von Daten oder Anweisungen zu erreichen, die zuvor aus einem Speicher 116 übertragen wurden.
  • Der Cache 126 kann mit dem Prozessorkern 122 integral verpackt sein. Der Cache 126 kann Anweisungsarrays (nicht gezeigt) und Datenarrays 141 aufweisen, die unter Verwendung von Hochgeschwindigkeitsspeichereinheiten ausgeführt sind. Anweisungen und Daten können an den jeweiligen Cache weitergeleitet werden, indem ein Signal geprüft wird, das einen Hinweis darauf gibt, ob der Prozessorkern eine Operation anfordert, deren Operand Anweisung versus Daten ist. Der Cache 126 kann des Weiteren ein zu dem Datenarray 141 gehörendes Cacheverzeichnis 142 aufweisen. Zum Beispiel hat jede Cachezeile in dem Datenarray 141 einen entsprechenden Eintrag in dem Cacheverzeichnis 142. Das Cacheverzeichnis 142 kann angeben, ob die durch eine effektive Adresse gekennzeichneten Daten in dem Datenarray 141 gespeichert sind. Zum Beispiel kann eine Prozessoranweisung, die eine effektive Adresse referenziert, dem Cache 126 bereitgestellt werden. Falls sich die effektive Adresse in dem Cacheverzeichnis 142 befindet, weiß der Prozessor, dass er die referenzierten Daten in Abhängigkeit davon, dass Zugriffskriterien erfüllt sind, aus dem Datenarray 141 erhalten kann, wobei es die Zugriffskriterien erforderlich machen können, dass das Gültig-Bit gesetzt ist, usw. Die effektive Adresse enthält zum Beispiel ein Tag-Feld, ein Zeilenindex-Feld und ein Byte-Feld. Das Tag-Feld der effektiven Adresse wird zur Bereitstellung von Cache-„Treffer“-Informationen genutzt, wie hierin beschrieben ist. Das Zeilenindexfeld der effektiven Adresse wird genutzt, um N Cachezeilen z.B. innerhalb des Datencachearrays 141 zu erhalten, die von dem Zeilenindexfeld indexiert werden, wobei N die Anzahl der Sätze in einem N-assoziativen Cachespeicher ist. Eine der N Cachezeilen kann unter Verwendung einer Satzkennung (als Teil eines late select) ausgewählt werden und das Byte-Feld der effektiven Adresse wird genutzt, um ein bestimmtes Byte innerhalb der ausgewählten Cachezeile zu indexieren.
  • Das Datenarray 141 und das Cacheverzeichnis 142 können aus herkömmlichen Speicherarrays gebildet werden, wie sie in Konfigurationen von zum Beispiel 4-M- oder 8-M-Chiparrays jederzeit verfügbar sind. Der Cache 126 gehört zu einem Cachecontroller (nicht gezeigt), der zum Beispiel die Übertragung von Daten zwischen dem Prozessorkern 122 und den Caches verwaltet.
  • Das Datencachearray 141 hat viele Cachezeilen, die die verschiedenen Datenwerte einzeln speichern. Die Cachezeilen sind in Gruppen von Cachezeilen unterteilt, die als „Sätze“ bezeichnet werden. Eine beispielhafte Cachezeile enthält ein Zustandsbit-Feld, ein Exklusivitätsbit-Feld und ein Wert-Feld, um die eigentliche Anweisung oder die eigentlichen Daten zu speichern. Das Zustandsbit-Feld und Inklusivitätsbit-Felder werden verwendet, um die Cache-Kohärenz in einem Mehrprozessor-Computersystem aufrechtzuerhalten. Das Adresstag ist ein Subset der vollständigen Adresse des entsprechenden Speicherblocks. Eine Vergleichsübereinstimmung einer eingehenden effektiven Adresse mit einem der Tags innerhalb des Adresstag-Felds gibt einen Cache-„Treffer“ an. Die Gruppe aller Adresstags in einem Cache (und manchmal das Zustandsbit-Feld und die Inklusivitätsbit-Felder) wird als ein Verzeichnis bezeichnet und die Gruppe aller Wert-Felder ist das Cacheeintragsarray.
  • Der Cache 126 kann als Level-1-(L1-)Cache und der Cache 130 kann als Level-2-(L2-)Cache bezeichnet werden, da er den (L1-)Cache 126 unterstützt. Zum Beispiel kann der Cache 130 als Vermittler zwischen dem Speicher 116 und dem L1-Cache fungieren und eine größere Menge an Informationen (Anweisungen und Daten) speichern, als es der L1-Cache kann, jedoch mit dem Nachteil einer längeren Zugriffszeit. Zum Beispiel kann der Cache 130 eine Speicherkapazität von 256 oder 512 Kilobyte haben, während der L1-Cache einen Gesamtspeicher von 64 Kilobyte haben kann. Der Cache 130 ist mit dem Bus 120 verbunden und das gesamte Laden von Informationen aus dem Speicher 116 in den Prozessorkern 122 kann durch den Cache 130 erfolgen. Obgleich 1 nur eine zweistufige Cachehierarchie darstellt, können mehrstufige Cachehierarchien bereitgestellt werden, bei denen es viele Stufen von seriell verbundenen Caches gibt. Zum Beispiel können die Komponenten der Verarbeitungseinheit 101 auf einem einzigen integrierten Chip untergebracht sein.
  • Ebenfalls in 1 gezeigt ist ein Adressumsetzpufferspeicher (TLB) 143, um eine effektive Adresse in eine entsprechende absolute Adresse umzusetzen. Genauer gesagt, der TLB 143 kann den Seitenzahlteil einer effektiven Adresse in eine entsprechende reale Seitenzahl umsetzen. Zum Beispiel kann das Tag-Feld einer effektiven Adresse an einen TLB 143 gesendet werden, um in eine entsprechende reale Seitenzahl umgesetzt zu werden.
  • In einem weiteren Beispiel kann das Computersystem 100 mindestens zwei Adressumsetzpufferspeicher aufweisen, von denen ein erster (TLB1) ein Pufferspeicher der ersten Stufe und ein zweiter (TLB2) ein Adressumsetzpufferspeicher der zweiten Stufe ist, die so angeordnet sind, dass sie dem ersten Adressinformationen zuführen, falls dem ersten eine Adresse fehlt. Zum Beispiel können die Adressumsetzungstabellen im Speicher eine Struktur mit mehreren Ebenen aufweisen. Bei einer Tabelle mit zwei Ebenen zum Beispiel enthält die Tabelle der ersten Stufe, die als Segmenttabelle bezeichnet wird, Einträge, die jeweils ein MB an Speicher punktweise einer als Seitentabelle bezeichneten Tabelle der zweiten Stufe zuordnen, welche 256 Einträge enthält, die 4 KB an Speicher zuordnen. Der TLB2 kann zwei Arten von Einträgen haben: 1-MB-Segmente und einzelne 4-KB-Seiten. Wenn eine Umsetzung im TLB der ersten Stufe (TLB1) nicht zur Verfügung steht, wird der TLB2 nach einem 4-KB-Seiteneintrag durchsucht, der die benötigte Umsetzung bereitstellt. Wenn nicht, wird der TLB2 nach einem Segmenteintrag für das Segment durchsucht, das die umzusetzende Adresse enthält. Wenn ein solcher Eintrag gefunden wird, wird die Umsetzung, welche die Tabellen im Speicher verwendet, kurzgeschlossen, da auf die entsprechende Seitentabelle direkt zugegriffen werden kann, ohne dass auf die Segmenttabelle im Speicher zugegriffen werden muss. Und der TLB1 kann ein 2-dimensionales Array mit Einträgen aufweisen, das z.B. 32 Einträge lang und 4 Einträge breit ist. Jeder Eintrag enthält eine virtuelle Adresse, die umgesetzt wurde, und die reale Adresse, in die sie umgesetzt wurde. In diesem Beispiel kann der TLB 143 der TLB1 sein.
  • In einem Beispiel kann das Computersystem 100 als eine Hardwareressource in einer virtualisierten Umgebung wie beispielsweise z/VM von IBM verwendet werden. Zum Beispiel kann die Verarbeitungseinheit 101 Anforderungen von virtuellen Maschinen oder einem Gast, der unter einem Hypervisor in einer logischen Partition ausgeführt wird, empfangen.
  • 2 ist ein Blockschaubild, das ein Schaubild für den Zugriff auf eine Cachestruktur 200 eines Cachespeichers mit einem zweistufigen Cache ü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 im L1-Cache und n Sätze im L2-Cache aufweist, m kann gleich n sein oder auch nicht. Die Cachestruktur 200 weist einen L1-Cache 226 und einen L2-Cache 230 auf. Der L1-Cache 226 weist, wie unter Bezugnahme auf 1 beschrieben ist, ein Datencachearray 141 und ein Cacheverzeichnis 142 auf. In 2 weist der L1-Cache 226 des Weiteren 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 wird unter Verwendung der Zeilenindexbits des Zeilenindex-Felds 210 der effektiven Adresse 201 logisch indexiert und unter Verwendung einer ersten Gruppe von Bits 212a des Tag-Felds 212 der effektiven Adresse 201 logisch getaggt. Das Validierungsverzeichnis 205 wird unter Verwendung der Zeilenindexbits des Zeilenindex-Felds 210 der effektiven Adresse 201 und Satzbits logisch indexiert. Das Validierungsverzeichnis 205 wird unter Verwendung einer zweiten Gruppe von Bits 212b des Tag-Felds 212 der effektiven Adresse 201 logisch getaggt. Die erste und die zweite Gruppe von Bits 212a und 212b sind zum Zweck der beispielhaften Erläuterung als nicht überlappend gezeigt. Die erste Gruppe und die zweite Gruppe von Bits können sich jedoch überlappen. Zum Beispiel kann die zweite Gruppe von Bits die Bits 0:49 aufweisen, die es ermöglichen können, dass man gelockerte Satzverzeichnis-Aktualisierungsregeln hat, was es z.B. erlaubt, dass das Satzverzeichnis und das Validierungsverzeichnis nicht immer strikt synchron sein müssen.
  • Jeder Eintrag des Satzverzeichnisses 203 weist mindestens die erste Gruppe von Bits 212a und ein Gültig-Bit auf. Wenn der Prozessorkern zum Beispiel Threads (z.B. die Threads th1 und th2) unterstützt, kann der Eintrag ein zu jedem Thread gehörendes Gültig-Bit aufweisen (z.B. kann der Eintrag wie folgt sein: LA.37:49, th0 vld, th1 vld). Jeder Eintrag des Validierungsverzeichnisses 205 weist mindestens die zweite Gruppe von Bits auf. In einem Beispiel weist der Eintrag des Validierungsverzeichnisses 205 des Weiteren ein Gültig-Bit, ein Exklusivitätsbit und einen Schlüssel auf. Das Gültig-Bit zeigt an, dass der Eintrag gültig ist. Das Exklusivitätsbit zeigt an, dass die Cachezeile in Exklusivbesitz ist. Es wird als Exklusivitätsbit bezeichnet, weil kein anderer Kern eine Kopie der zugehörigen Zeile haben kann, wenn eine Zeile einem Kern exklusiv gehört. 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 Speicherschlüssel zum Schutz und kann einen beliebigen anderen Satz von sonstigen Informationen enthalten. In einem Beispiel weist der Eintrag des Validierungsverzeichnisses 205 des Weiteren ein ASCE-Element und ein REAL-Element auf, wobei sich ASCE auf ein Adressraum-Steuerelement (address space control element) (Zeiger auf dynamische Adressumsetzungstabellen) bezieht und das REAL-Element angibt, dass es sich bei dem Eintrag um einen realen Eintrag handelt.
  • Die L1- und L2-Cachearrays 141 halten die Datenkopie aus dem Speicher 116 und jeder Eintrag in dem L1- und dem L2-Verzeichnis 142 und 242 hält die zweite Gruppe von Bits 212b, die Adressraumkennung usw. Das L1-Verzeichnis 142 zum Beispiel enthält die folgenden Felder: Gültig-Bit, logische Adresse, z.B. 45:49, und L2-Satz-ID. Das Gültig-Bit gibt an, ob der L1-Verzeichniseintrag gültig oder nicht gültig ist. Die logische Adresse 45:49 ist eine Erweiterung der logischen Adresse 50:55 des L1, um den Zugriff des L2-Verzeichnisses zu gestatten. 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 sein: setO - L2CC(45:49), th0 logdir vld, th1 logdir vld, ptrdir vld, wobei L2CC(45:49) die Bits 45:49 der effektiven Adresse (die auch als logische Adresse bezeichnet wird) sind. Das Bit 45 wird nur für den Datencache gespeichert, da L2 für Daten die Größe 4M hat, während L2 für Anweisungen die Größe 2M hat. „logdir vld“ zeigt an, dass die in dem L1-Cache gespeicherte Umsetzung gültig ist. „ptrdir vld“ ist ein Gültig-Bit, das anzeigt, dass die Daten in dem L1-Cache gültig sind. Die Bits „45:49“ können zum Beispiel aus den Cachegrößen (z.B. der Anzahl der Zeilen) abgeleitet werden. Wenn der L1-Cache zum Beispiel 64 Zeilen je Satz hat, ist der Zeilenindex 50:55, und wenn der L2 1024 Zeilen je Satz hat, kann die Indexierung breiter sein, was zu einem Index 45:55 führt. Da das L1-Verzeichnis jedoch bereits mit 50:55 indexiert wurde, kann das Zeigen auf eine L2-Koordinate durchgeführt werden, indem lediglich LA.46:49 sowie die L2-Satz-ID in dem Eintrag des L1-Verzeichnisses beibehalten werden.
  • Um die Beschreibung von 2 zu vereinfachen, kann ein vereinfachtes Beispiel des L1-Caches betrachtet werden. In diesem Beispiel hat der L1-Cache 64 Zeilen und 8 Sätze (d.h. m=8) und eine Cachezeile wird unter Verwendung der logischen Adresse adressiert, die 64 Bit (0:63) (abgekürzt LA(0:63)) hat. Daher beträgt die Zeilengröße in diesem Beispiel 256 Byte. In diesem Beispiel kann das Satzverzeichnis 203 LA(37:49) als ein Tag (die erste Gruppe von Bits) verwenden. Das Tag des Validierungsverzeichnisses 205 kann LA(0:49) oder LA(0:36) zuzüglich zusätzlicher Informationen sein, die zur Unterscheidung zwischen verschiedenen Adressräumen benötigt werden.
  • Das Validierungsverzeichnis 205 kann als ein „gestapeltes“ („Stacked“) logisches Verzeichnis bezeichnet werden, da das Validierungsverzeichnis aus einer einzelnen physischen Array-Struktur erstellt wird, die einen Verzeichniseintrag je Zeile hält. Dem vorstehenden Beispiel folgend, weist das Validierungsverzeichnis 8 x 64 Zeilen = 512 Zeilen anstelle von acht Array-Strukturen, von denen jede 64 Zeilen hat, auf. Der Vorteil einer solchen Struktur kann darin bestehen, dass eine Array-Zeile nur eine begrenzte Anzahl von Bits (aus physischen Gründen) haben kann. Das Hinzufügen von weiteren Zeilen geht mit einem vergleichsweise geringen zusätzlichen Aufwand in Bezug auf das Vergrößern der Breite einer Zeile oder das Hinzufügen von weiteren Array-Strukturen einher. Das „gestapelte“ Konzept kann vorteilhaft sein, da es gegebenenfalls weniger Fläche und Strom verbraucht. Das L1-Cacheverzeichnis 142 hat jedoch acht Array-Strukturen, von denen jede 64 Zeilen hat.
  • 2 veranschaulicht des Weiteren Einzelheiten 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 Komparatoren 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 Komparatoren 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 Folgendes aufweisen: „set0 - AA.17:51“, wobei setO der Satzindex des Satzes ist, der den Eintrag aufweist, AA die absolute Adresse ist, die zu der effektiven Adresse gehört, welche für die Indexierung des L2-Verzeichnisses verwendet wird. In einem weiteren Beispiel kann der Eintrag des L2-Verzeichnisses des Weiteren zwei zusätzliche Elemente „key(0:3), FP “ aufweisen, wobei „key“ ein 4-Bit-Tag ist, das gemäß Regeln, die in den Architekturgrundsätzen (z.B. z/architecture) des Betriebs des Computersystems 100 beschrieben sind, gegebenenfalls übereinstimmen muss, und die FP-Abrufsperre ermöglicht den Schlüsselvergleich.
  • Die Cachestruktur 200 weist des Weiteren den TLB 143 auf.
  • Bei einer Suche im Cache 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 oder sagt den Satz vorher, der eine als Set(0:7) bezeichnete Satz-ID hat, welche die angeforderte Cachezeile hält. Zum Beispiel kann das Satzverzeichnis 203 durchsucht werden, um die Satz-ID zu finden. Unter Verwendung der Satz-ID Set(0:7) zusätzlich zu dem Index LA(50:55) wird das Validierungsverzeichnis 205 durchsucht, um den Cachetreffer unter Verwendung des Tag-Vergleichs 220 zu bestätigen, was dazu führen kann, dass ein entsprechender Verzeichniseintrag in dem Validierungsverzeichnis 205 gekennzeichnet wird. Zum Beispiel wird dafür die durch das Satzverzeichnis 203 festgelegte Satz-ID verwendet, um eine der acht 64-Zeilen-Abschnitte auszuwählen, und LA(50:55) wird verwendet, um die Zeile innerhalb des Abschnitts auszuwählen.
  • Parallel zum Durchsuchen des Satzverzeichnisses 203 wird das L1-Cacheverzeichnis 142 durchsucht, um das Gültig-Bit für diesen Verzeichniseintrag abzurufen. Die gültigen Teile sind Teil des L1-Cacheverzeichnisses 142, da gegebenenfalls mehrere Einträge auf einmal ungültig gemacht werden müssen. Wenn der Tag-Vergleich 220 einen Treffer 244 erkennt und das Gültig-Bit gesetzt ist, gibt der Gültig-Vergleich 240 an, dass ein Cachetreffer gefunden wurde. Andernfalls kann ein Cachefehler 245 gefunden werden. Das Datenarray 141 kann eine Satzkennung aus dem Satzverzeichnis 203 empfangen und Daten der angeforderten Cachezeilen unter Verwendung des Zeilenindexes 210 und des Byte-Offsets 213 der effektiven Adresse 201 sowie 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 falls die Suche in dem Satzverzeichnis 203 fehlschlägt (zu einem Cachefehler führt), werden die Datenstrukturen in dem unteren Teil von 2 einbezogen. Und zwar wird der TLB 143 unter Verwendung der effektiven Adresse 201 durchsucht und unter Verwendung des Treffervergleichs 251 (der Teile der logischen Adresse 201 und umsetzungsrelevante Informationen wie beispielsweise eine Adressraumkennung enthält) wird die absolute Adresse für die Anforderung festgestellt. Der Treffervergleich 251 kann durch eine eigene Vergleichslogik des TLBs durchgeführt werden. Parallel zum Durchsuchen des TLBs 143 wird das L2-Cacheverzeichnis 242 durchsucht, wobei z.B. die Bits 46:55 der effektiven Adresse 201 verwendet werden. Und der Treffervergleich 261 sucht nach einem Treffer in dem L2-Cacheverzeichnis 242, indem er die durch den TLB ausgegebene absolute Adresse mit den absoluten Adressen des L2-Cacheverzeichnisses vergleicht, die unter Verwendung der logischen Adresse 201 gekennzeichnet wurden. Das Ergebnis des Treffervergleichs 261 ist ein Hinweis darauf, welcher L2-Satz den Treffer erkannt hat (die Zeichnung geht von 8 Sätzen (d.h. n=8) in dem L2-Cache aus). Diese Trefferinformationen werden dann in dem L1-Verzeichnisvergleich 270 verwendet, um festzustellen, ob die Zeile, die in dem L2-Cache zu einem Treffer führt, auch bereits im L1-Cache gespeichert ist. Dafür verwendet der L1-Verzeichnisvergleich 270 auch empfangene eingegebene logische Zeiger (die als out1 bis outm bezeichnet werden) auf den L2-Cache. Jeder logische Zeiger (z.B. out1) wird einem jeweiligen L1-Satz zugeordnet und weist den L2-Index und die L2-Satz-ID und ein Gültig-Bit des Eintrags des L1-Verzeichnisses auf, das dem Index LA(50:55) entspricht.
  • 3 ist ein Ablaufplan eines Verfahrens zum Betreiben des Cachespeichers von 2. Nach dem Empfang einer Zugriffsanforderung z.B. über eine effektive oder logische Adresse für den Zugriff auf eine bestimmte Cachezeile wird im Schritt 310 auf das Satzverzeichnis 203 (das als setp bezeichnet wird) und das L1-Cacheverzeichnis 142 (das als ptdir bezeichnet wird) zugegriffen. Dieser 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 oder auch nicht führen, die den Satz angibt, in dem die Cachezeilen vorhanden sind. Der Zugriff auf das L1-Cacheverzeichnis 142 kann zu mehreren Einträgen von jeweiligen L1-Sätzen führen oder auch nicht führen, da das L1-Cacheverzeichnis als Eingabe nur die Zeilenindexbits der effektiven Adresse verwendet.
  • Im Falle (Abfrage 220) eines Cachefehlers, der sich aus dem Durchsuchen des Satzverzeichnisses 203 ergibt, können die Schritte 380 bis 387 durchgeführt werden. Im Falle (Abfrage 220) eines Cachetreffers können die 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.
  • Im Schritt 330 kann das Validierungsverzeichnis 205 (das als logdir bezeichnet wird) unter Verwendung der Satzkennung, die von dem Satzverzeichnis 203 empfangen wird, und der Zeilenindexbits der effektiven Adresse (z.B. LA(50:55)) durchsucht werden.
  • Im Schritt 340 kann das zu der adressierten Cachezeile gehörende Gültig-Bit festgestellt werden. Dieses kann festgestellt werden, indem der Eintrag der mehreren Einträge unter Verwendung der Satzkennung ausgewählt und der Wert des Gültig-Bits des ausgewählten Eintrags gelesen wird.
  • Falls (350) das Validierungsverzeichnis 205 einen Cachefehler als Ergebnis des Suchlaufs 330 bereitstellt oder das Gültig-Bit einen Wert hat, der einen ungültigen Zustand anzeigt, kann der Eintrag des Satzverzeichnisses, auf den die Suche des Schritts 310 getroffen ist, ungültig gemacht werden 370. Andernfalls kann ein Cachetreffer im Schritt 360 aufgelöst werden, indem z.B. ein Treffersignal bereitgestellt wird.
  • Im Schritt 380 wird eine TLB-Suche unter Verwendung der logischen Adresse der Anforderung durchgeführt. Das Ergebnis dieser Suche ist die übereinstimmende absolute Adresse. Als Nächstes, im Schritt 381, wird das L2-Cacheverzeichnis 242 durchsucht und mit der von dem TLB bereitgestellten absoluten Adresse verglichen. Im Falle eines L2-Fehlers verzweigt der Schritt 382 zu 383, um den L1-Fehler und den L2-Fehler aufzulösen. Nach erfolgter Auflösung des L1-Fehlers und des L2-Fehlers werden alle Datenstrukturen aktualisiert, so dass die Cachezeile bei der nächsten Anforderung in dem Satzverzeichnis 203 gefunden werden kann.
  • Wenn der Schritt 382 einen L2-Treffer erkennt, vergleicht der Schritt 384 den Inhalt des L1-Cacheverzeichnisses, der durch den Suchlauf im Schritt 310 gekennzeichnet wurde, mit dem Inhalt des L2-Verzeichnisses, um festzustellen, ob sich die Cachezeile tatsächlich im L1 befindet. Wenn das Ergebnis des Vergleichs einen L1-Treffer ergibt, entscheidet sich der Schritt 385 für eine Verzweigung zum Schritt 386. Dies ist der Fall, wenn die Anforderung in dem Satzverzeichnis 203 zu keinem Treffer führte, sich die Cachezeile aber tatsächlich in dem L1-Cache befindet. Dies kann zum Beispiel der Fall sein, weil das Satzverzeichnis nicht richtig ist, oder es könnte sein, weil die aktuelle Anforderung für ein anderes Synonym ist als das Synonym, das bisher in dem L1 gespeichert war (was für die aktuelle Anforderung das Gleiche wie die Aussage „das Satzverzeichnis war nicht richtig“ ist). So oder so aktualisiert der Schritt 386 das Satzverzeichnis 203 und das Validierungsverzeichnis 205 so, dass sie mit der aktuellen Anforderung übereinstimmen. Es muss keine tatsächliche Datenübertragung stattfinden. Wenn der Schritt 385 keinen L1-Treffer erkannt hat, zeigt dies an, dass sich die Cachezeile nicht im L1-Cache befindet - ganz gleich welches Synonym -, sondern sich im L2-Cache befindet. Daher wird der L1-Fehler im Schritt 387 aufgelöst, was eine Übertagung von Daten aus dem L2 an den L1 und das Aktualisieren des Satzverzeichnisses und des Validierungsverzeichnisses beinhaltet, so dass nach der wiederholten Anforderung ein L1-Treffer gefunden wird.
  • Auf jeden der Schritte 370, 383, 386 und 387 folgt der Schritt 399, um die Anforderung zu wiederholen, die gegebenenfalls 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.
  • Im Schritt 401 wird eine zweite effektive Adresse (die als Synonym B bezeichnet wird) empfangen. Die zweite effektive Adresse ist ein Synonym für eine zuvor verarbeitete effektive Adresse, die als Synonym A bezeichnet wird. Anders ausgedrückt, das Synonym B wird für eine Cachezeile verwendet, während sich ein weiteres Synonym A bereits in dem L1-Cache befindet.
  • Zum Zweck der beispielhaften Erläuterung zeigt 4 das Adressensynonym A und B in hexadezimal. Der Einfachheit halber sind 20 Bitadressen (5 hexadezimale Ziffern) gezeigt. In diesem Beispiel ist der Byteindex oder -Offset in die Cachezeile nicht gezeigt. Bits sind von links nach rechts nummeriert (das Bit 0 ist das höchstwertige Bit), so dass jede Adresse die Bits 0:19 hat. Synonym A = 12345 und Synonym B = 67895. In diesem Beispiel kann das Satzverzeichnis 203 unter Verwendung der Bis 16:19 (d.h. der letzten hexadezimalen Ziffer der Adresse) indexiert und unter Verwendung der Bits 8:15 getaggt werden. Wie in 4 gezeigt ist, sind drei beispielhafte Anwendungsfälle A) bis C) 430 dargestellt.
  • Im Anwendungsfall A) haben die Synonyme A und B denselben Index (setp-Index =5) und unterschiedliche Tags in dem Satzverzeichnis 203. Die Synonyme A und B bilden auf dieselbe absolute Adresse ab.
  • Im Anwendungsfall B haben die Synonyme A und B denselben Index (setp-Index =5) und dieselben Tags in dem Satzverzeichnis 203. Die Synonyme A und B bilden auf dieselbe absolute Adresse ab.
  • Im Anwendungsfall C haben die Zeilen A und B denselben Index (setp-Index =5) und dieselben Tags in dem Satzverzeichnis 203. Sie bilden jedoch auf verschiedene absolute Adressen ab.
  • Im Schritt 403 wird das Satzverzeichnis 203 durchsucht, um einen Cachetreffer für das angeforderte Synonym B zu kennzeichnen. Dies wird als ein „Satzverzeichnis falsch“-Fall betrachtet, weil das Satzverzeichnis 203 einen Satz bereitgestellt hat, der letzten Endes nicht wirklich einen Treffer erkannt hat.
  • Die Suche im Schritt 405 nach dem Synonym B in dem Validierungsverzeichnis 205 würde jedoch zu einem Cachefehler führen. Wenn die Suche für das Synonym A wäre, würde die Suche in dem Validierungsverzeichnis 205 einen Treffer erkennen (und der Schritt 360 kann ausgeführt werden). Da der Zugriff jedoch für das Synonym B war, stimmt die aus dem Validierungsverzeichnis 205 gelesene Adresse nicht mit der angeforderten Adresse überein.
  • Im Schritt 407 wird der Eintrag, der dem Synonym B in dem Satzverzeichnis 203 entspricht, ungültig gemacht. Und der wiederholte Zugriff unter Verwendung des Synonyms B wird im Schritt 409 ausgelöst.
  • Die Schritte 403 bis 420 werden für die Anwendungsfälle B) und C) ausgeführt.
  • Im Schritt 411 wird das Satzverzeichnis 203 durchsucht, um einen Cachefehler für das angeforderte Synonym B zu kennzeichnen.
  • Nach dem Kennzeichnen des Cachefehlers des Schritts 411 wird der Schritt 413 ausgeführt. Im Schritt 413 (der den Schritt 384 durchführt) wird der Inhalt des L1-Cacheverzeichnisses, der zu dem Synonym B gehört, mit dem Inhalt des L2-Verzeichnisses verglichen, der zu dem Synonym B gehört, um festzustellen, dass sich die Cachezeile tatsächlich im L1 befindet.
  • Nach dem Kennzeichnen oder Finden des Cachetreffers im Schritt 314 können das Satzverzeichnis 203 und das Validierungsverzeichnis 205 im Schritt 415 aktualisiert werden. Die Aktualisierung kann zum Beispiel durchgeführt werden, indem Informationen des Synonyms A mit dem Synonym B überschrieben werden.
  • Nach dem Durchführen der Aktualisierung des Schritts 415 kann die Wiederholung des Zugriffs unter Verwendung des Synonyms B im Schritt 417 ausgelöst werden. Der wiederholte Zugriff führt zu einem Satzverzeichnis-Treffer im Schritt 428, gefolgt von einem Validierungsverzeichnis-Treffer im Schritt 419, was dazu führt, dass der Cachezugriff im Schritt 420 aufgelöst wird.
  • Die Schritte 411 bis 420 können für den Anwendungsfall A) ausgeführt werden. Wenn zum Beispiel das Synonym B des Anwendungsfalls A) empfangen wird, kann wie im Schritt 411 ein Fehler gefunden werden. Anders ausgedrückt, nur die Schritte 411 bis 420 können für ein empfangenes Synonym B des Anwendungsfalls A) ausgeführt werden.
  • 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 Tag-Feld 212 und ein Cachezeilen-Indexfeld 210 aufweist.
  • Im Schritt 501 können eine erste Gruppe von Bits 212a und eine zweite Gruppe von Bits 212b des Tag-Felds 212 festgelegt werden.
  • Im Schritt 503 können die Zeilenindexbits und die erste Gruppe von Bits 212a der effektiven Adresse in dem Satzverzeichnis 203 gesucht werden, wobei eine Satzkennung erzeugt wird, um den Satz anzugeben, der eine Cachezeile der effektiven Adresse 201 enthält.
  • Im Schritt 505 können die Satzkennung und die Zeilenindexbits 210 und die zweite Gruppe von Bits 212b der effektiven Adresse 201 in dem Validierungsverzeichnis 205 gesucht werden, um das Vorhandensein der Cachezeile in dem Satz zu überprüfen, der die im Schritt 503 bereitgestellte Satzkennung hat. Dieser Schritt 505 kann das Vorhandensein oder Nichtvorhandensein der Cachezeile in dem Satz angeben oder bestätigen, indem angegeben wird, ob sie in dem Validierungsverzeichnis 205 vorhanden ist.
  • Als Reaktion auf die Feststellung des Vorhandenseins der Cachezeile in dem Satz, welche auf dem zweiten Suchlauf des Schritts 505 beruht, kann im Schritt 507 ein Treffersignal erzeugt werden. Das Treffersignal kann verwendet werden, um die Daten der Cachezeile aus dem Datenarray 141 bereitzustellen.
  • In einem Beispiel kann der Schritt 503 und/oder der Schritt 505 zu einem Cachefehler führen, da die gesuchte Adresse nicht in dem Satzverzeichnis 203 bzw. nicht in dem Validierungsverzeichnis gefunden wird. In diesem Fall kann der Cachefehler bestätigt werden, indem auf den TLB 143 und das sekundäre Cacheverzeichnis 242 zugegriffen wird, wie mit den Schritten 380 bis 399 beschrieben wird.
  • TLB-INVALIDIERUNGEN
  • Gemäß einer einzelnen Ausführungsform weist das Verfahren des Weiteren als Reaktion auf das Empfangen einer Anforderung für das Ungültigmachen eines Validierungsverzeichniseintrags des Validierungsverzeichnisses das entsprechende Setzen eines Gültig-Bits des entsprechenden primären Cacheverzeichniseintrags in dem primären Cacheverzeichnis auf.
  • Gemäß einer einzelnen Ausführungsform weist das Verfahren des Weiteren das Bereitstellen einer ersten Zusatzdatenstruktur zusammen mit dem primären Cacheverzeichnis, wobei jeder Eintrag der ersten Zusatzdatenstruktur Bits der effektiven Adresse aufweist, die in TLB-Löschanforderungen des Mehrprozessorsystems angegebene Informationen widerspiegeln, das Kennzeichnen eines Eintrags in der ersten Zusatzdatenstruktur, der der empfangenen Anforderung entspricht, wobei der gekennzeichnete Eintrag den Eintrag in dem primären Cacheverzeichnis angibt, auf.
  • Wenn zum Beispiel ein Adressraum für ein Gast-Betriebssystem durch einen entsprechenden Hypervisor entfernt wird, befinden sich die Cachezeilen immer noch im L1-Cache. Es gibt jedoch keine gültige Umsetzung mehr für sie. Das bedeutet, dass eine Anforderung, die die entfernte Umsetzung verwendet, keinen Zugriff auf die Daten in dem L1-Cache haben sollte. Um diese Einträge unzugänglich zu machen, sollten sie in dem L1-Cache ungültig gemacht werden, weil das L1-Cacheverzeichnis logisch getaggt ist. Vor dem Ungültigmachen sollten die betroffenen Einträge gefunden werden. Ein Bit kann zum Beispiel als Teil der Eintragsinformationen in dem Validierungsverzeichnis verwendet werden, um anzugeben, dass ein bestimmter Eintrag zu einem Gast-Betriebssystem gehört. Wenn die TLB-Invalidierung alle Umsetzungsinformationen in Bezug auf dieses Gast-Betriebssystem entfernt, sollten alle Verzeichniseinträge in dem Validierungsverzeichnis 205, bei denen das Gast-Bit gesetzt ist, ungültig gemacht werden.
  • Bei dem Validierungsverzeichnis 205 kann jederzeit nur ein Eintrag angeschaut werden, um herauszufinden, ob er ungültig gemacht (oder gelöscht) werden soll oder nicht. Um dieses Problem zu mildern, wird das L1-Verzeichnis 142 um eine Nebenstruktur „ptrdirext“ (d.h. die erste Zusatzdatenstruktur) erweitert, die umsetzungsrelevante Informationen für jeden Eintrag in dem Validierungsverzeichnis 205 hält. Wie bei dem L1-Verzeichnis kann auf alle Sätze in der ersten Zusatzdatenstruktur parallel zugegriffen werden. Zum Beispiel kann ein Eintrag der ersten Zusatzdatenstruktur „setO - th ASCE(44:49), PGSZ(0:1), SX(37:43)“ aufweisen, wobei sich PGSZ auf die Seitengröße bezieht (z.B. können Ergebnisse einer dynamischen Adressumsetzung für Seitengrößen von 4k, 1M oder 2G sein), SX(37:43) bezieht sich auf die Bits 37:43 der effektiven Adresse und ASCE(44:49) sind die Bits 44:49 der effektiven Adresse, die als Adressraumkennung durch einen jeweiligen Thread th verwendet werden.
  • Zum Beispiel kann eine Folge von virtuellen Adressen, die zu einem virtuellen Speicher gehören, auf den ein Adressraum-Steuerelement (ASCE) zeigt, als Adressraum bezeichnet werden. Adressräume können verwendet werden, um Trennungsgrade zwischen Benutzern bereitzustellen. Die Struktur der ersten Zusatzdatenstruktur kann es ermöglichen, zu einem bestimmten Adressraum gehörende Einträge unter Verwendung der ASCE-Bits wirksamer zu löschen.
  • Mit dieser Nebenstruktur können TLB-Invalidierungen, die nur bestimmte Umsetzungen betreffen sollten, deutlich schneller vorgenommen werden, als wenn man alle Einträge in dem Validierungsverzeichnis einzeln durchginge.
  • Die Nebenstruktur ptrdirext wird zusammen mit einer beliebigen Aktualisierung in dem Validierungsverzeichnis 205 geschrieben. Ein Kompromiss zwischen der Größe von ptrdirext und der Genauigkeit von TLB-Invalidierungen kann eingegangen werden. Um den Fall der Gast- im Vergleich zu der Hypervisor-Eigentümerschaft anzugehen, wird ein einzelnes Bit benötigt, um die Unterscheidung zu treffen. Wenn eine TLB-Löschung beruhend auf einer Adressraumkennung wie beispielsweise der ASCE bei der z/Architecture, d.h. einem 51-Bit-Wert sowie einiger Steuerinformationen, vorgenommen wird, kann es ausreichen, lediglich ein paar Bits oder einen Hash von einigen Bits zu speichern, um herauszufiltern, welche Einträge gelöscht werden müssen und welche nicht. Eine Beispiel-Ausführung von ptrdirext könnte einen Teil der ASCE-Bits, Kennungsbits auf Gastebene, eine Seitengröße-Angabe (für TLB-Architekturen, die mehrere Seitengrößen unterstützen), einen Segmentindex oder einen Teil des Segmentindexes halten (für TLB-Architekturen, die mehrstufige Seitentabellen unterstützen, bei denen eine höhere Stufe als „Segmenttabelle“ bezeichnet wird und auf der Segmenttabelle beruhende Invalidierungen möglich sind). Wenn das Gültig-Bit zum Beispiel Teil der L1-Verzeichniseinträge ist, kann die tatsächliche Invalidierung von Einträgen auch parallel zu allen Einträgen eines Satzes in einem bestimmten L1-Verzeichnis erfolgen.
  • Zum Zweck der Beschreibung der folgenden Figuren wird die folgende Terminologie verwendet.
  • Der eigentliche Speicherzugriff wird unter Verwendung einer „realen“ Adresse vorgenommen. Dies könnte zum Beispiel ein 64-Bit-Wert sein, der Hauptspeicherpositionen adressiert. Jedoch kann ein beliebiger Wert oder ein beliebiges Konzept für ein Adressierungssystem verwendet werden.
  • Anweisungen, die auf dem Prozessorkern ausgeführt werden, verwenden „logische“ Adressen. Falls keine dynamische Adressumsetzung (DAT, dynamic address translation) verwendet wird, wird der Prozessor im „realen“ Adressierungsmodus ausgeführt und die von dem Programm verwendete logische Adresse wird auch als die reale Adresse verwendet.
  • Bei Verwendung von DAT wird der Prozessor im „virtuellen“ Adressierungsmodus ausgeführt. Zu virtuellen Adressierungsinformationen gehören die von Anweisungen angegebene logische Adresse sowie zusätzliche Informationen, um einen bestimmten Adressraum zu kennzeichnen, wie beispielsweise das Address Space Control Element (ASCE), das man zum Beispiel in der von International Business Machines (IBM) angebotenen z/Architecture findet. Andere Konzepte für eine Umsetzung von virtuell in real können jedoch verwendet werden. Dieser virtuelle Adressierungsmodus kann verwendet werden, um jedem Programm seinen eigenen Adressraum zu geben, wobei verschiedene Abbildungen von logischen in reale Adressen verwendet werden.
  • VIRTUELLER CACHE
  • Das Tag 600 des („logdir“-)Verzeichnisses 142 des virtuellen Caches (das hierin als „logdir“ bezeichnet wird) hält alle Informationen in Bezug auf Umsetzungen, die ein herkömmlicher Adressumsetzpufferspeicher (TLB) 143 üblicherweise hält. 6 ist eine schematische Darstellung eines beispielhaften logdir-Tags 600 gemäß Ausführungsformen. Das Tag 600 enthält die logischen Adressbits 601, die als die Bits 0:49 veranschaulicht sind, eine Adressraumkennung 602 (die hier als „ASCE“ veranschaulicht ist), eine Anzeige für ein „reales“ Bit R 603 (das eine Adresse als virtuell im Vergleich zu real markiert), einen Virtuelle-in-reale-Adresse-Anzeiger 604 und möglicherweise anderen Inhalt 605.
  • In dem vorstehend mit Bezug auf die 1 bis 5 beschriebenen Konzept und in der ebenfalls anhängigen United States Patent Application 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 übernommen werden, können mehrere Umsetzungen nicht gleichzeitig zusammen in dem Verzeichnis vorhanden sein.
  • REALE UND VIRTUELLE UMSETZUNGEN
  • Betriebssysteme verwenden reale Adressen oftmals direkt. Das heißt, eine Adressumsetzung ist nicht erforderlich, um die eigentlichen Informationen, Anweisungen oder Daten zu finden, die von dem Prozessor gehalten werden. Im logdir eines virtuellen Caches bedeutet dies, dass der Eintrag als eine „reale“ Adresse markiert wird, indem das „R“-Bit 603 so gesetzt wird, dass es anzeigt, dass keine Adressumsetzung erforderlich ist.
  • Jedes Programm, das auf einem zugehörigen Betriebssystem ausgeführt wird, verwaltet jedoch gewöhnlich in seinem eigenen Adressraum ...., wobei es zum Beispiel DAT verwendet, um virtuellen Speicher bereitzustellen. Cachezeilen, auf die in dieser Weise zugegriffen wird, können gekennzeichnet werden, indem das „R“-Bit 603 gelöscht wird. Das heißt, das „R“-Bit 603 wird gesetzt, um anzuzeigen, dass die Adresse nicht die reale Adresse ist und eine Adressumsetzung erforderlich ist, um die eigentlichen Informationen, Daten oder Anweisungen, die zu dieser Cachezeile gehören, zu lokalisieren.
  • Für bestimmte Adressbereiche, die zwischen dem Betriebssystem und Benutzercode geteilt werden (z.B. Programme, die auf dem Betriebssystem betrieben werden), kann das Betriebssystem eine virtuelle Adressabbildung für den Benutzercode erzeugen, die die logische Adresse in dieselbe reale Adresse umsetzt. Nehmen wir zum Beispiel an, dass die Adresse 0x1000 für den Austausch von Informationen zwischen dem Betriebssystem und dem Benutzercode verwendet wird. Das Betriebssystem greift unter Verwendung von realen Adressen auf den gesamten Speicher zu. Der Benutzercode greift unter Verwendung von virtuellen Adressen auf den gesamten Speicher zu. Für Benutzercode wird die logische Adresse 0x1000 auf die reale Adresse 0x1000 abgebildet.
  • 7 veranschaulicht einen Prozess zur Datenübertragung durch die gemeinsam genutzte Speicherposition, wenn das Virtuell-in-Real-Bit 604 in dem logdir-Tag 600 nicht vorhanden (z.B. nicht enthalten) ist, die virtuelle und die reale Adresse aber dieselbe Adresse sind. Bei diesem Konzept findet die folgende Abfolge von Ereignissen für eine Datenübertragung durch die gemeinsam genutzte Speicherposition statt.
  • Der Prozess beginnt, wenn der Benutzercode einen Code an einer virtuellen Adresse speichert. Dies ist im Schritt 710 veranschaulicht. Zum Beispiel kann der Benutzercode einen Funktionscode an der virtuellen Adresse speichern. Zum Zweck dieser Erörterung ist die virtuelle Adresse 0x1000. Eine beliebige Adresse kann jedoch verwendet werden. Um dies auszuführen, erstellt logdir 600 einen virtuellen Verzeichniseintrag für diese bestimmte Cachezeile, wobei DAT ein- und das R-Bit an der logischen Adresse 0x1000 (die z.B. eine virtuelle Adresse angibt) ausgeschaltet ist. Dieser Wert eines Eintrags für die Cachezeile zeigt an, dass der Adressraum für den Benutzercode ist, der den Code in der Cachezeile gespeichert hat.
  • Als Nächstes ruft der Benutzercode das zugrunde liegende Betriebssystem auf. Dies ist im Schritt 720 veranschaulicht. Der Benutzercode ruft das zugrunde liegende Betriebssystem unter Verwendung der zu dem Betriebssystem gehörenden Protokolle auf, deren Einzelheiten hierin nicht ausführlicher erörtert werden. In einigen Ausführungsformen greift der Benutzercode über einen Hypervisor auf das zugrunde liegende Betriebssystem zu, der die Ausführung von virtuellen Maschinen auf dem zugrunde liegenden Betriebssystem ermöglicht.
  • Als Reaktion auf den Aufruf von dem Benutzercode liest das Betriebssystem den Code von der realen Adresse. Dies ist im Schritt 730 veranschaulicht. In diesem Schritt liest das Betriebssystem den Code von der realen Adresse 0x1000 (die gleich der virtuellen Adresse ist). Dies führt zu einem logdir-Fehler. Da der Zugriff auf die reale Adresse nach einem Eintrag in logdir sucht, bei dem das reale Bit 603 eingeschaltet ist (z.B. R=1). Somit sollte das Synonym R=0 unter Verwendung des Umladeprozesses, der vorstehend mit Bezug auf die 1 bis 5 beschrieben wurde, bereinigt werden. Diese Bereinigung ist im Schritt 740 veranschaulicht. Als Folge der Bereinigung wird der logdir-Eintrag für die Cachezeile auf den realen Eintrag für die Cachezeile aktualisiert. Dies führt dazu, dass die DAT auf „aus“ und das R-Bit 603 auf „ein“ für die logische Adresse 0x1000 gesetzt wird.
  • Nach jeder folgenden Iteration, in der die Benutzercodes einen weiteren Funktionscode an der virtuellen Adresse 0x1000 speichern, tritt ein logdir-Fehler auf, weil das reale Bit auf „ein“ gesetzt ist. Dies führt dazu, dass das Synonym erneut bereinigt und logdir entsprechend aktualisiert werden muss. Dies kann sich bei jeder Verwendung der gemeinsam genutzten Adresse wiederholen. Es sei angemerkt, dass der hierin erörterte Vergleich des R-Bits 603 notwendig ist, da es möglich ist, dass man einen anderen logdir-Eintrag hat, bei dem die Abbildung von einer logischen Adresse in eine reale Adresse anders ist. Das heißt, bei der virtuellen Adresse und der realen Adresse handelt es sich nicht um dieselben logischen Adressen.
  • Um diese vorstehend mit Bezug auf 7 veranschaulichten Bereinigungsaktionen von Synonymen von virtuellen/realen Adressen anzugehen, kann ein neues Bit zu dem logischen Verzeichnis hinzugefügt werden. Dies ist der Virtuell-in-real-Anzeiger 604. Dieses Bit 604 kann als „V=R“ („virtuelle Adresse ist gleich der realen Adresse“) bezeichnet werden. Das V=R-Bit 604 wird gesetzt, wenn die reale Adresse, die das Ergebnis einer DAT-„ein“-Adressumsetzung ist, gleich der logischen Adresse ist, mit der sie begonnen hat (d.h., die logische Adresse ist die reale Adresse). In dem vorstehend mit Bezug auf 7 erörterten Beispiel würde das V=R-Bit infolge einer Umsetzung der virtuellen Adresse 0x1000 für Benutzercode in die reale Adresse 0x1000 gesetzt werden.
  • Um den Wert des V=R-Bits zu setzen, bei dem die virtuelle Adresse gleich der realen Adresse ist, wird der Prozess der Adressumsetzung erweitert. 8 veranschaulicht den Erweiterungsprozess. Der Schritt 810 veranschaulicht den bisherigen vorhandenen Adressumsetzungsprozess. Ein beliebiger Adressumsetzungsprozess kann in diesem Schritt ausgeführt werden. Um den Umsetzungsprozess aufzurufen, wird eine Anforderung für eine logische Adresse 801 oder eine Real-im-Vergleich-zu-DAT-ein-Anforderung (real vs DAT on request) 802 empfangen. Als Reaktion auf die Anforderung stellt der Prozess fest, ob es eine Anforderung für eine reale Adresse gibt. Dies ist im Schritt 820 veranschaulicht. Wenn die Anforderung für eine reale Adresse ist, gibt ein neuer Komparator eine V=R-Anzeige aus, wenn die resultierende reale Adresse und die eingegebene logische Adresse identisch sind. Dies ist im 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 die V=R-Information ebenfalls zurückgeben kann. Alternativ kann die V=R-Anzeige nach jeder TLB-Suche auch neu berechnet werden. Bei diesem Konzept ist es möglich, die zusätzlichen Bits in dem TLB zu sichern, jedoch um den Preis, dass der V=R-Vergleichsprozess in dem TLB-Suchpfad stattfindet.
  • Um Zugriff auf den Eintrag sowohl als virtuelle als auch als reale Adresse zu gestatten, wird auch die Verzeichnistreffer-Vergleichslogik erweitert. In Ausführungsformen gilt, wenn eine Suche nach einer V=R-Adresse als Teil einer Suche im virtuellen Cache stattfindet, die normale Verzeichnisvergleichslogik. Wenn jedoch die Suche nach einer realen Adresse stattfindet und das V=R-Bit in dem Verzeichniseintrag gesetzt ist, werden alle DAT-„ein“-Informationen wie beispielsweise das ASCE ignoriert. Auf diese Weise kann der Verzeichniseintrag sowohl als virtueller als auch realer Eintrag verwendet werden. 9 veranschaulicht eine Beispiel-Ausführung eines Verzeichnisvergleichs, der die V=R-Logik der vorliegenden Offenbarung einschließt. Im unteren Teil der Figur befindet sich ein 3-Wege-AND 910 im unteren Teil von 9 berechnet die „Treffer“-Informationen für die Cachezeile. Die linke Eingabe 920 des AND 910 führt den Vergleich der für die DAT-„ein“-Bedingung im logdir relevanten Informationen durch. Wenn die DAT eingeschaltet („ein“) ist und der Eingang eine Eingabe für den V=R-Fall empfängt und wenn es eine Anforderung für eine reale Adresse ist und das V=R-Bit gesetzt ist, werden die DAT-„ein“-Informationen ignoriert. Der mittlere Eingang 930 des AND 910 empfängt das Ergebnis des Vergleichs der logischen Adresse. Der rechte Eingang 940 des AND 910 qualifiziert den Vergleich mit dem angeforderten Adressmodus. Entweder ist die Anforderung virtuell und der Verzeichniseintrag ist ebenfalls virtuell, oder es sind beide real oder die Anforderung ist, bei dem erweiterten V=R, real und der Eintrag ist V=R. Diese mit Bezug auf die 8 und 9 erörterte Erweiterung wird in den Prozess eingefügt, der in 7 als der Schritt 750 veranschaulicht ist. In diesem Schritt wird im Anschluss an die Bereinigung des Synonyms im Schritt 740 das V=R-Bit auf einen Wert gesetzt, der anzeigt, dass V=R „ein“ oder wahr ist. In einigen Ausführungsformen kann die DAT an diesem Punkt in Abhängigkeit von der Logik, die von dem Benutzercode oder dem Betriebssystem beim Zugriff auf das, was sie für virtuelle Adressen halten, auf „ein“ zurückgesetzt werden.
  • Was nun die 10 bis 17 angeht, wird ein Prozess zum Verwalten von Umsetzungen über verschiedene Threads hinweg erörtert.
  • UMSETZUNGEN IN VERSCHIEDENEN THREADS
  • Das Tag des Verzeichnisses 142 des virtuellen Caches („logdir“) hält alle Informationen in Bezug auf Umsetzungen, die ein TLB wie beispielsweise der TLB 143 üblicherweise hält. 10 veranschaulicht ein Beispiel-Tag 1000 gemäß veranschaulichenden Ausführungsformen. Das Tag 1000 enthält die Bits 0:49 (1001) der logischen Adresse, eine Adressraumkennung 1002 („ASCE“), eine Anzeige für ein „reales“ Bit 1003 (die eine Adresse als „braucht keine Adressumsetzung“ markiert, gewöhnlich zur Verwendung durch das Betriebssystem) und anderen Inhalt, der erforderlich oder hilfreich ist, um einen Cachetreffer im Vergleich zu einem Cachefehler gemeinsam festzustellen, 1004. In einigen Ausführungsformen kann das Tag das vorstehend mit Bezug auf die 6 bis 9 erörterte V=R-Bit enthalten.
  • In einigen Mikroprozessor-Architekturen wie beispielsweise der von International Business Machines (IBM) angebotenen z/Architecture wird die Gültigkeit einer Adressumsetzung je Thread definiert. Daher ist ein Cacheverzeichniseintrag in dem logdir, der von einem Thread erstellt wurde, nicht unbedingt für andere Threads gültig. Der Verzeichnissuchprozess beinhaltet keine Durchführung der tatsächlichen Adressumsetzung. Daher beinhaltet der Verzeichnissuchprozess keine Prüfung, ob die Adressumsetzung aktuell gültig ist. Stattdessen wird die Adressumsetzung entweder nach der Erstellung oder nach der Aktualisierung eines Eintrags durchgeführt (und ihre Gültigkeit geprüft).
  • In dem vorstehend mit Bezug auf die 1 bis 5 beschriebenen Konzept und in der ebenfalls anhängigen United States Patent Application Nr. 15/625,223 mit dem Titel „Cache structure using a logical directory“, eingereicht am 16. Juni 2017, deren Inhalte hiermit durch Bezugnahme erneut in ihrer Gesamtheit übernommen werden, können mehrere Threads unterstützt werden, indem das Verzeichnis-Tag um ein zusätzliches Feld erweitert wird, das den Thread kennzeichnet, der den Cacheverzeichniseintrag erstellt hat. Die vorstehend erörterten Regeln befolgend, wechselt die Thread-Eigentümerschaft zwischen Threads (indem sie „Umladungen“ ausführt), wenn ein von dem aktuellen Eigentümer des Cacheverzeichniseintrags abweichender Thread auf die gemeinsam genutzte Cachezeile zugreifen möchte. Wenn die Änderung der Eigentümerschaft der gemeinsam genutzten Cachezeile häufig vorkommt, schafft dieser dauernde Wechsel der Eigentümerschaft der Cachezeile ein Performanzproblem.
  • Die vorliegende Offenbarung geht dieses Performanzproblem an, indem sie threadweise Gültig-Bits zu dem Cacheverzeichnis 1005 hinzufügt. In dem vorstehend erörterten Entwurf wird dies erreicht, indem threadweise Gültig-Bits in dem ptrdir hinzugefügt werden. Die TLB-Invalidierungen können auch funktionieren, indem man nur Einträge für den Thread anschaut, der die TLB-Invalidierung vornimmt, und nur die Gültig-Bits von diesem Thread ausschaltet. Auf diese Weise können andere Threads weiterhin auf die Cachezeile zugreifen, selbst nachdem ein Thread seine Umsetzung in diese Zeile „verloren“ hat.
  • In den vorliegenden Ausführungsformen ist es möglich, dass ein Thread eine Cachezeile in dem L1-Cache besitzt, ohne dass er irgendwelche gültigen Umsetzungen für die Cachezeile hat. Beide Threads, die auf die Umsetzungen zugreifen, hätten ihre Umsetzungen unabhängig voneinander ungültig machen lassen können, was zu einem Eintrag für eine Cachezeile ohne gültige Umsetzung in sie führt. In einigen Ausführungsformen ist aus anderen Mikroarchitektur-Gründen ein Bit „Cachezeile immer noch im L1“ erwünscht, ein weiteres Gültig-Bit („Zeile gültig“) 1006 kann zu dem Cacheverzeichnis hinzugefügt werden, das erst nach einer vollständigen Invalidierung einer Cachezeile ausgeschaltet werden kann. Eine vollständige Invalidierung einer Cachezeile kann zum Beispiel als eine gegenseitige Invalidierung von einem anderen Prozessorkern aus stattfinden. In Ausführungsformen, die dieses Konzept einsetzen, wird eine Cachezeile als für eine bestimmte Suche gültig betrachtet, wenn das Gültig-Bit des Suchthreads gesetzt ist, was die Umsetzung in die Cachezeile als gültig kennzeichnet, und das „Zeile-gültig“-Bit gesetzt ist.
  • Mit dem Hinzufügen der threadweisen Gültig-Bits zu dem Cacheverzeichnis wird der Prozess, um zwei Threads die gemeinsame Nutzung derselben Cachezeile unter Verwendung derselben Umsetzung zu gestatten, nachstehend mit Bezug auf 11 und 12 erörtert. Der nachstehend erörterte Prozess geht von zwei verschiedenen Threads, die auf dieselbe Cachezeile zugreifen, sowie davon aus, dass sich die Cachezeile nicht im L1-Cache, sondern bereits zu Beginn des Prozesses im L2-Cache befand. 13 erörtert und veranschaulicht den vollständigen Entscheidungsprozess von 11 und 12.
  • 11 veranschaulicht einen Prozess eines ersten Threads, der versucht, gemäß Ausführungsformen auf eine bestimmte Cachezeile zuzugreifen. Der Prozess beginnt, wenn der erste Thread feststellt, dass es in dem L1-Cache einen logdir-Fehler gibt. Dies ist im Schritt 1110 veranschaulicht. Ein logdir-Fehler tritt auf, wenn der Thread versucht, den bestimmten Eintrag in dem Cacheverzeichnis zu finden. Ein Cachefehler tritt auf, wenn der Thread den L1-Cache nach der bestimmten Cachezeile durchsucht, die Cachezeile aber in dem L1-Cache nicht findet.
  • Im Anschluss an den logdir-Fehler fährt der Prozess mit der Durchführung eines ptrdir-Vergleichs fort. Dies ist im Schritt 1120 veranschaulicht. In diesem Schritt stellt der Prozess fest, dass die Cachezeile überhaupt nicht in dem L1-Cache gefunden wird. Der ptrdir-Vergleich wird durch einen beliebigen bekannten Prozess durchgeführt, der für eine ptrdirim Vergleich zu einer L2-Verzeichnis-/TLB-Suche verwendet wird.
  • Als Nächstes führt der Prozess einen L2-Verzeichnisvergleich durch, um die gewünschte Cachezeile zu finden. Dies ist im Schritt 1130 veranschaulicht. In diesem Schritt stellt der Prozess fest, dass die Cachezeile in dem L2-Cache vorhanden ist. Wäre die Cachezeile nicht in dem L2-Cache gefunden worden, würde der Prozess diesen Schritt für den L3-Cache oder einen beliebigen Cache einer niedrigeren Stufe, der in der Prozessorstruktur vorhanden ist, bis zu dem Zeitpunkt wiederholen, zu dem er die gewünschte Cachezeile findet. Da die Cachezeile in dem L2-Cache gefunden wird, kennzeichnet der Prozess diese Cachezeile für ein erneutes Laden in den L1-Cache.
  • Sobald die Cachezeile in dem L2 oder einem niedrigeren Cache gekennzeichnet wurde, fährt der Prozess fort, um einen neuen Verzeichniseintrag für die Cachezeile in dem L1-Cache zu erstellen. Dies ist im Schritt 1140 veranschaulicht. In diesem Schritt kann der Prozess einen bereits vorhandenen Eintrag in dem Cacheverzeichnis zum Überschreiben wählen. In einigen Ausführungsformen ist der zu überschreibende Eintrag der älteste Eintrag. In einigen Ausführungsformen ist der Eintrag, der überschrieben wird, der Eintrag, auf den eine Zeit lang nicht zugegriffen wurde. In einigen Ausführungsformen ist der Eintrag der Eintrag mit den wenigsten Zugriffen. Jedoch kann ein beliebiges Konzept für die Auswahl des zu überschreibenden Verzeichniseintrags verwendet werden. Sobald der Verzeichniseintrag zum Überschreiben ausgewählt wird, fährt der Prozess fort, um die L1-Cachedatenstrukturen für die Cachezeile zu aktualisieren, und setzt das Gültigkeitsbit für den Thread, um anzuzeigen, dass der erste Thread der Eigentümer der Cachezeile ist. Gleichzeitig wird das Gültigkeitsbit für den zweiten Eigentümer-Thread für die Cachezeile ungültig gemacht. Die Invalidierung des Gültigkeitsbit für den anderen Thread wird vorgenommen, weil bei dem anderen Thread in dem Verzeichniseintrag, der überschrieben wird, ein Gültig-Bit gesetzt worden sein könnte. Die neue Umsetzung (Cachezeileneintrag) ist nicht unbedingt auch für den anderen (zweiten) Thread gültig.
  • Nachdem die Cachezeile in den L1-Cache geladen wurde, kann der erste Thread bei Bedarf auf diesen Eintrag treffen. Dies ist im Schritt 1150 veranschaulicht. Das heißt, der erste Thread kann auf das zugehörige logdir in dem L1-Cache zugreifen und es finden.
  • 12 ist ein Prozessdiagramm, das einen Prozess für einen zweiten Thread veranschaulicht, um den Cacheeintrag im Anschluss an den Prozess von 11 gemäß Ausführungsformen zu suchen. Der Prozess von 12 ist ähnlich dem vorstehend mit Bezug auf 11 erörterten Prozess und zum Zweck der Erörterung von 12 werden die Einzelheiten von ähnlichen Schritten hier nicht ausführlicher erörtert. Der Prozess beginnt, wenn der zweite Thread eine logdir-Suche durchführt und einen Treffer für das logdir in dem L1-Cache findet. Dies ist im Schritt 1210 veranschaulicht.
  • Im Anschluss an die Feststellung, dass sich die Cachezeile in dem L1-Cache befand, stellt der Prozess fest, dass die Cachezeile für den zweiten Thread nicht gültig ist. Dies ist im Schritt 1220 veranschaulicht. Die Gültigkeit für den zweiten Thread ist nicht gültig, da die Gültigkeit der Umsetzung für den Eintrag lediglich für den ersten Thread festgestellt wurde. Der Prozess zur Feststellung, ob die Cachezeile für den zweiten Thread gültig ist, kann unter Verwendung eines beliebigen bekannten Verfahrens zur Feststellung, dass eine Cachezeile gültig ist, ausgeführt werden.
  • Da die Cachezeile für den zweiten Thread nicht gültig ist, wird eine ptrdir- und L2-Verzeichnis-/TLB-Suche durchgeführt. Dies ist im Schritt 1230 veranschaulicht. In diesem Schritt stellt der zweite Thread fest, dass die Cachezeile in dem L1-Cache vorhanden ist. (Verschoben nach L1 durch den Prozess von 11). Es wird festgestellt, dass sich die Stelle des Cachezeilen-Treffers in derselben Cachezeile befindet, in der auch der logdir-Treffer im Schritt 1210 gefunden wurde. Dieser Treffer auf derselben Cachezeile bestätigt, dass sich die Umsetzung bereits in dem L1-Cache befindet und die Umsetzung mit der Umsetzung für den ersten Thread übereinstimmt.
  • Das Gültig-Bit des L1-Caches für den zweiten Thread wird eingeschaltet. Dies ist im Schritt 1240 veranschaulicht. Des Weiteren bleibt auch das Gültig-Bit für den ersten Thread auf „ein“. 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 schematische Darstellung, die den kombinierten Prozess von 11 und 12 veranschaulicht, der als ein Entscheidungsbaum gemäß Ausführungsformen dargestellt ist.
  • Wenn im Schritt 1310 kein logdir-Treffer erkannt wird und im Schritt 1320 kein ptrdir-Treffer erkannt wird, befindet sich die Cachezeile derzeit nicht in dem L1-Cache. Somit stellt der Schritt 1330 beruhend auf dem Ergebnis der L2-Verzeichnissuche fest, ob die Cachezeile aus dem L2-Cache (Pfad (A)) oder dem L3-Cachepfad (B) erneut geladen werden soll (was mit Bezug auf 14 ausführlicher erörtert wird).
  • Wenn der ptrdir-Vergleich im Schritt 1320 jedoch einen Treffer erkennt, befindet sich die Zeile bereits in dem L1-Cache. In einem Fall wird das L1-Verzeichnis aktualisiert, damit es mit den Informationen der aktuellen anfordernden Threads übereinstimmt (Schritt 1321). Das Gültig-Bit für den aktuellen Thread wird gesetzt, die Gültig-Bits für alle anderen werden ungültig gemacht (Schritt 1322). Abermals wird dieser Schritt durchgeführt, weil aufgrund der Aktualisierung des Verzeichnisses auf die Informationen der aktuellen Anforderung die Umsetzungsinformationen in dem Verzeichnis für andere Threads möglicherweise nicht mehr richtig sind.
  • Wenn der logdir-Vergleich einen Treffer ergibt, der Schritt 1340 das Gültig-Bit für den anfordernden Thread-Satz aber nicht findet, begibt sich der Baum zum nächsten Schritt 1350 und prüft das Ergebnis des ptrdir-Vergleichs. Wenn kein Treffer erkannt wird, befindet sich die Cachezeile nicht im L1 und es folgt der Schritt 1360, der gleich dem Schritt 1330 ist, um die Cachezeile in den L1 zu bringen. Wenn der ptrdir-Vergleich 1350 einen Treffer ergibt, vergleicht der Schritt 1370 die setid des ptrdir-Treffers mit der setid des logdir-Treffers aus dem Schritt 1310. Wenn sie übereinstimmen, befindet sich die Cachezeile der aktuellen Anforderung bereits im L1, mit den richtigen logdir-Tag-Informationen. Nur das Gültig-Bit fehlt für den zweiten Thread. Daher wird das Gültig-Bit für den aktuellen anfordernden Thread eingeschaltet, und falls andere Gültig-Bits bereits aktiv waren, wird die Cachezeile nun zwischen mehreren Threads geteilt. Wenn der setid-Vergleich 1370 ergibt, dass der L1-Treffer auf einer anderen setid erfolgte, wird dieser Eintrag auf die Informationen des aktuellen anfordernden Threads aktualisiert, das Gültig-Bit des aktuellen anfordernden Threads wird gesetzt und die Gültig-Bits von allen anderen Threads werden wieder gelöscht. Dies ist im Schritt 1371 veranschaulicht.
  • 14 ist ein Ablaufplan, der das Auflösen eines L1-Cachefehlers gemäß Ausführungsformen veranschaulicht. Der Einstieg in den Prozess 1400 erfolgt entweder von dem Pfad A oder dem Pfad B von 13. Der Pfad A stellt einen L1-Cachefehler und einen L2-Cachetreffer dar, während der Pfad B einen L1-Cachefehler und einen L2-Cachefehler darstellt. Beim Einstieg in den Prozess 1400 vom Pfad A im Schritt 1401 wird die Cachezeile aus dem L2-Cache abgerufen. Beim Einstieg in den Prozess 1400 vom Pfad B im Schritt 1402 wird die Cachezeile aus dem L3-Cache abgerufen. Sobald die Zeile abgerufen wird, schreibt der Prozess im Schritt 1403 alle L2-Datenstrukturen, die bei jeder wiederholten Suche auf der L3-Cachezeile zu einem Treffer führen. Im Anschluss an den Schritt 1401 oder aber den Schritt 1403 (in Abhängigkeit von dem Einstiegspfad) laufen die Prozesse zusammen. Im Schritt 1410 werden die L1-Datenstrukturen, die bei jeder nachfolgenden Suche auf dieser Cachezeile zu einem Treffer führen, geschrieben. Im Schritt 1420 wird das Gültig-Bit in dem Cachezeileneintrag für den entsprechenden Thread gesetzt, der die bestimmte Cachezeile angefordert hat. Die Suche kann im Schritt 1430 wiederholt werden.
  • VERSCHIEDENE UMSETZUNGEN IN VERSCHIEDENEN THREADS
  • In einem Kern für simultanes Multithreading (simultaneous multithreading, SMT) braucht jeder Thread möglicherweise eine eigene Umsetzung für eine absolute Adresse, die zwischen Threads geteilt wird. Bei dem vorstehend beschriebenen Konzept der gemeinsamen Nutzung von Threads führt dies dazu, dass der Thread 1 während der L1-Verzeichnissuche nicht die richtigen Informationen (z.B. logische Adresse, ASCE ...) findet. Daher wäre es falsch, das Gültig-Bit für diesen Thread zu setzen, obgleich der ptrdir- im Vergleich zu dem L2-Verzeichnis-/TLB-Vergleichsprozess ergibt, dass sich die richtige Cachezeile bereits in dem L1-Cache befindet. Eine andere Umsetzung (d.h. die Umsetzung aus dem ersten Thread) würde letzten Endes für diese Zeile verwendet werden. Bei diesem Konzept kann die Situation so gehandhabt werden, als ob es in der Cachezeile kein Gültig-Bit eines threadweisen Verzeichnisses gäbe, d.h. eine Umladung durchgeführt wird. Der logdir-Eintrag des vorhandenen (ersten) Threads wird mit den Informationen des zweiten Threads überschrieben und das Gültig-Bit des anderen ersten Threads wird ausgeschaltet.
  • 15 veranschaulicht eine Lösung für die gemeinsame Nutzung von Cachezeilen in einem logdir, die gemäß Ausführungsformen verschiedene Umsetzungen verwenden. Unter der Annahme von zwei Threads werden die vollständigen Verzeichnistaginformationen dupliziert. Das Ergebnis des Tag-Vergleichs wird weiter qualifiziert, wobei die Anforderung für den ersten Thread für das Verzeichnis des ersten Threads und die Anforderung für den zweiten Thread für das Verzeichnis des zweiten Threads ist. Ein Verzeichnistreffer findet statt, wenn eines der Treffersignale aktiv ist.
  • In einigen Ausführungsformen ist es nicht notwendig, beide Verzeichnisse tatsächlich einzuschalten. Die Thread-ID einer Anforderung wäre frühzeitig in dem Prozess bekannt. Die Kenntnis der entsprechenden Thread-ID kann verwendet werden, um Strukturen auszuschalten, die für den „anderen“ Thread vorgesehen sind. Folglich, während der logdir-Bereich dupliziert wird, in einigen Ausführungsformen insbesondere für einen Kern mit zwei Threads, der eher hohe Stromsparanforderungen als Flächeneinsparungsanforderungen hat. Dieses Konzept macht die Notwendigkeit überflüssig, das Tag-Vergleichsergebnis bei der Suche in dem L1-Cache des Threads zu berücksichtigen, der eine Cachezeile anteilig nutzen möchte. Der Thread hat seinen ganz eigenen Verzeichniseintrag und braucht nicht an den vorhandenen Verzeichniseintrag des anderen Threads angepasst zu werden.
  • 16 veranschaulicht ein Konzept, bei dem einige der Verzeichnisinhalte zwischen Threads geteilt werden. Dieses Konzept gestattet nur teilweise unterschiedliche Tag-Informationen. Somit kann ein Teil des mit einem threadweisen Verzeichnis verbundenen Aufwands eingespart werden. Entscheidend ist, dass je nach den tatsächlichen Fällen, in denen Adressen zwischen Threads geteilt werden, nicht alle Tag-Informationen unterschiedlich sind. Zum Beispiel kann Speicher, der zwischen verschiedenen Programmen geteilt wird, die in verschiedenen Threads ausgeführt werden, auf dieselben logischen Adressen abgebildet werden und nur eine andere Adressraumkennung verwenden. In diesem Fall muss nur das ASCE je Thread anders sein. Dies ist häufig der Fall, wenn gemeinsam genutzte Bibliotheken verwendet werden.
  • In einigen Ausführungsformen wird das Tag dann in einen ASCE-Teil, der je Thread dupliziert wird (im logdir des ersten Threads/threadspezifischen logdir des zweiten Threads), und in die verbleibenden Bits aufgeteilt, die in einem von Threads gemeinsam genutzten logdir gespeichert werden. Die threadspezifischen Strukturen müssen wiederum nur für die Anforderung des aktuellen Threads eingeschaltet werden. Der letzte Treffer wird infolge der threadweisen und der von Threads gemeinsam genutzten Tag-Treffer berechnet.
  • 17 ist eine schematische Darstellung des Entscheidungsbaums gemäß 13, der modifiziert wurde, um die teilweise gemeinsame Nutzung von threadweisen Informationen in dem logdir gemäß Ausführungsformen zu verarbeiten. Verweise auf die Pfade A und B in 17 beziehen sich auf die Pfade von 14. Bei getrennten threadspezifischen und von Threads gemeinsam genutzten Teilen in dem Verzeichnis sind die bei einer Suche im Cache zu treffenden Entscheidungen gegenüber 13 leicht modifiziert. Der Schritt 1310 wird modifiziert, um beruhend auf dem von Threads gemeinsam genutzten Teil des logdir zu entscheiden. Dies ist im Schritt 1710 veranschaulicht. Der Schritt 1340 wird modifiziert, um beruhend auf dem Ergebnis des Gültig-Bits für den anfordernden Thread und dem logdirspezifischen Treffer zu entscheiden. Dies ist im Schritt 1740 veranschaulicht. Der Schritt 1371 wird modifiziert, um nicht nur das Gültig-Bit zu aktualisieren, sondern er schreibt auch in den threadspezifischen Teil des logdir. Dies ist im Schritt 1771 dargestellt. Dennoch, wenn der ptrdir-Vergleich im Schritt 1770 den Treffer in der „falschen“ setid erkennt (z.B. nicht derjenigen mit dem von Threads gemeinsam genutzten Treffer), sollte der L1-Verzeichnisinhalt aktualisiert werden. Dies schließt sowohl den von Threads gemeinsam genutzten als auch den threadspezifischen Teil des logdir ein. Grund hierfür ist die Aktualisierung des von Threads gemeinsam genutzten Teils, ohne zu wissen, dass es die gültige Umsetzung für andere Threads notwendig macht, die Gültig-Bits des anderen Threads auszuschalten.
  • 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.
  • 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 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 [0091, 0107]

Claims (19)

  1. Virtuelles Cacheverzeichnis in einem Prozessor mit Unterstützung eines virtuellen Speichers und mehrerer Threads, wobei das virtuelle Cacheverzeichnis eine Vielzahl von Verzeichniseinträgen hat, wobei jeder Eintrag zu einer Cachezeile gehört, wobei das virtuelle Cacheverzeichnis aufweist: ein zu jedem der Vielzahl der Verzeichniseinträge gehörendes Tag, wobei das Tag aufweist: eine logische Adresse; eine Adressraumkennung; einen Bitanzeiger für eine reale Adresse; und ein threadweises Gültigkeitsbit für jeden Thread, der auf die Cachezeile zugreift.
  2. Virtuelles Cacheverzeichnis nach Anspruch 1, wobei die Cachezeile so konfiguriert ist, dass sie von mindestens zwei verschiedenen Threads auf einem Prozessor gemeinsam genutzt wird.
  3. Virtueller Cache nach Anspruch 1, der des Weiteren aufweist: ein Zeile-gültig-Bit, wobei das Zeile-gültig-Bit anzeigt, dass mindestens eine Umsetzung in der Cachezeile aktuell gültig ist.
  4. Virtueller Cache nach Anspruch 1, der des Weiteren aufweist: einen Virtuelle-Adresse-in-reale-Adresse-Anzeiger, der anzeigt, dass die logische Adresse gleich der realen Adresse ist.
  5. Virtueller Cache nach Anspruch 4, wobei, wenn der Virtuelle-Adresse-in-reale-Adresse-Anzeiger gesetzt ist, keine dynamische Adressumsetzung durchgeführt wird.
  6. Verfahren zum Betreiben eines primären Prozessor-Caches für einen Prozessor mit Unterstützung eines virtuellen Speichers und mehrerer Threads, wobei ein logisch indexiertes und logisch getaggtes Cacheverzeichnis verwendet wird und wobei ein Eintrag in dem Verzeichnis eine absolute Speicheradresse zusätzlich zu einer entsprechenden logischen Speicheradresse enthält, wobei jeder Eintrag ein Gültig-Bit für jeden Thread, der auf jeden Eintrag zugreift, enthält, wobei das Verfahren aufweist: Feststellen, durch einen ersten Thread, dass eine Cachezeile in dem primären Cache nicht vorhanden ist; Feststellen, dass sich die Cachezeile in einem sekundären Cache befindet; als Reaktion auf die Feststellung, dass sich die Cachezeile in dem sekundären Cache befindet, Erstellen eines neuen Eintrags für die Cachezeile in dem primären Cache; Feststellen, durch einen zweiten Thread, dass ein Eintrag für die Cachezeile in dem primären Cache vorhanden ist; als Reaktion auf die Feststellung, dass der Eintrag für die Cachezeile in dem primären Cache vorhanden ist, Feststellen, dass die Cachezeile für den zweiten Thread nicht gültig ist; Ausführen einer Suche, um eine Adresse für die Cachezeile in dem primären Cache festzustellen; Feststellen, dass es sich bei der Adresse für die Cachezeile und dem Eintrag um dieselbe Cachezeile handelt; als Reaktion auf die Feststellung, dass die Adresse und der Eintrag identisch sind, Setzen des zu dem zweiten Thread gehörenden Gültig-Bits auf gültig und Nicht-Ungültigmachen des zu anderen Threads in dem Cacheeintrag gehörenden Gültig-Bits.
  7. Verfahren nach Anspruch 6, wobei der sekundäre Cache ein L2-Cache ist.
  8. Verfahren nach Anspruch 6, wobei der sekundäre Cache ein L3-Cache ist.
  9. Verfahren nach Anspruch 6, wobei das Erstellen des neuen Eintrags einen vorherigen Eintrag in dem primären Cache überschreibt.
  10. Verfahren nach Anspruch 6, wobei das Erstellen des neuen Eintrags die Cachezeile aus dem sekundären Cache in den primären Cache kopiert.
  11. Verfahren nach Anspruch 10, wobei das Erstellen das zu dem ersten Thread in der Cachezeile gehörende Gültig-Bit auf „ein“ setzt.
  12. Verfahren nach Anspruch 11, wobei das Erstellen das zu beliebigen anderen Threads in der Cachezeile gehörende Gültig-Bit ungültig macht.
  13. Verfahren nach Anspruch 6, wobei die Feststellung, dass sich die Cachezeile nicht in dem primären Cache befindet, beruhend auf einem von Threads gemeinsam genutzten Eintrag in dem Verzeichnis festgestellt wird, und wobei der erste Thread einen threadspezifischen Eintrag in dem Cacheverzeichnis hat.
  14. Computerprogrammprodukt, das über durch einen Computer ausführbare Anweisungen zum Betreiben eines Prozessors mit Unterstützung eines virtuellen Speichers und mehrerer Threads verfügt, wobei ein logisch indexiertes und logisch getaggtes Cacheverzeichnis verwendet wird, und wobei ein Eintrag in dem Verzeichnis eine absolute Speicheradresse zusätzlich zu einer entsprechenden logischen Speicheradresse enthält, wobei jeder Eintrag ein Gültig-Bit für jeden Thread, der auf jeden Eintrag zugreift, enthält, die, wenn sie ausgeführt werden, mindestens einen Computer veranlassen, ein Verfahren auszuführen, das aufweist: Feststellen, durch einen ersten Thread, dass eine Cachezeile in dem primären Cache nicht vorhanden ist; Feststellen, dass sich die Cachezeile in einem sekundären Cache befindet; als Reaktion auf die Feststellung, dass sich die Cachezeile in dem sekundären Cache befindet, Erstellen eines neuen Eintrags für die Cachezeile in dem primären Cache; Feststellen durch einen zweiten Thread, dass ein Eintrag für die Cachezeile in dem primären Cache vorhanden ist; als Reaktion auf die Feststellung, dass der Eintrag für die Cachezeile in dem primären Cache vorhanden ist, Feststellen, dass die Cachezeile für den zweiten Thread nicht gültig ist; Ausführen einer Suche, um eine Adresse für die Cachezeile in dem primären Cache festzustellen; Feststellen, dass es sich bei der Adresse für die Cachezeile und dem Eintrag um dieselbe Cachezeile handelt; als Reaktion auf die Feststellung, dass die Adresse und der Eintrag identisch sind, Setzen des zu dem zweiten Thread gehörenden Gültig-Bits auf gültig und Nicht-Ungültigmachen des zu anderen Threads in dem Cacheeintrag gehörenden Gültig-Bits.
  15. Computerprogrammprodukt nach Anspruch 14, wobei der sekundäre Cache ein L2-Cache ist.
  16. Computerprogrammprodukt nach Anspruch 14, wobei das Erstellen des neuen Eintrags einen vorherigen Eintrag in dem primären Cache überschreibt.
  17. Computerprogrammprodukt nach Anspruch 14, wobei das Erstellen des neuen Eintrags die Cachezeile aus dem sekundären Cache in den primären Cache kopiert.
  18. Computerprogrammprodukt nach Anspruch 17, wobei das Erstellen das zu dem ersten Thread in der Cachezeile gehörende Gültig-Bit auf „ein“ setzt.
  19. Computerprogrammprodukt nach Anspruch 18, wobei das Erstellen das zu beliebigen anderen Threads in der Cachezeile gehörende Gültig-Bit ungültig macht.
DE112018002028.2T 2017-06-16 2018-06-14 Umsetzungsunterstützung für einen virtuellen cache Pending DE112018002028T5 (de)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US15/625,289 US10698836B2 (en) 2017-06-16 2017-06-16 Translation support for a virtual cache
US15/625,289 2017-06-16
PCT/IB2018/054357 WO2018229701A1 (en) 2017-06-16 2018-06-14 Translation support for a virtual cache

Publications (1)

Publication Number Publication Date
DE112018002028T5 true DE112018002028T5 (de) 2020-01-16

Family

ID=64656598

Family Applications (1)

Application Number Title Priority Date Filing Date
DE112018002028.2T Pending DE112018002028T5 (de) 2017-06-16 2018-06-14 Umsetzungsunterstützung für einen virtuellen cache

Country Status (5)

Country Link
US (4) US10698836B2 (de)
JP (1) JP7184815B2 (de)
DE (1) DE112018002028T5 (de)
GB (1) GB2577023B (de)
WO (1) WO2018229701A1 (de)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11403222B2 (en) 2017-06-16 2022-08-02 International Business Machines Corporation Cache structure using a logical directory
US11775445B2 (en) 2017-06-16 2023-10-03 International Business Machines Corporation Translation support for a virtual cache

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10776281B2 (en) * 2018-10-04 2020-09-15 International Business Machines Corporation Snoop invalidate filter for distributed memory management unit to reduce snoop invalidate latency
CN110363401B (zh) * 2019-06-26 2022-05-03 北京百度网讯科技有限公司 整合粘性评估方法、装置、计算机设备及存储介质
US20230315633A1 (en) * 2022-04-04 2023-10-05 International Business Machines Corporation Shadow pointer directory in an inclusive hierarchical cache

Family Cites Families (45)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4654790A (en) * 1983-11-28 1987-03-31 Amdahl Corporation Translation of virtual and real addresses to system addresses
JPS6299844A (ja) * 1985-10-28 1987-05-09 Hitachi Ltd アドレス変換装置
US4797814A (en) * 1986-05-01 1989-01-10 International Business Machines Corporation Variable address mode cache
JP2839060B2 (ja) 1992-03-02 1998-12-16 インターナショナル・ビジネス・マシーンズ・コーポレイション データ処理システムおよびデータ処理方法
JPH07287668A (ja) 1994-04-19 1995-10-31 Hitachi Ltd データ処理装置
JP3713312B2 (ja) 1994-09-09 2005-11-09 株式会社ルネサステクノロジ データ処理装置
KR970029072A (ko) 1995-11-17 1997-06-26 김주용 이중 디렉토리 가상 캐쉬 및 그 제어 방법
US6055605A (en) 1997-10-24 2000-04-25 Compaq Computer Corporation Technique for reducing latency of inter-reference ordering using commit signals in a multiprocessor system having shared caches
US6122709A (en) 1997-12-19 2000-09-19 Sun Microsystems, Inc. Cache with reduced tag information storage
US8135962B2 (en) 2002-03-27 2012-03-13 Globalfoundries Inc. System and method providing region-granular, hardware-controlled memory encryption
US7039768B2 (en) * 2003-04-25 2006-05-02 International Business Machines Corporation Cache predictor for simultaneous multi-threaded processor system supporting multiple transactions
US7873785B2 (en) 2003-08-19 2011-01-18 Oracle America, Inc. Multi-core multi-thread processor
US20050182912A1 (en) * 2004-02-12 2005-08-18 International Business Machines Corporation Method of effective to real address translation for a multi-threaded microprocessor
US7318127B2 (en) 2005-02-11 2008-01-08 International Business Machines Corporation Method, apparatus, and computer program product for sharing data in a cache among threads in an SMT processor
US7496730B2 (en) 2005-04-15 2009-02-24 Microsoft Corporation System and method for reducing the number of translation buffer invalidates an operating system needs to issue
US7363463B2 (en) 2005-05-13 2008-04-22 Microsoft Corporation Method and system for caching address translations from multiple address spaces in virtual machines
US7426627B2 (en) 2006-03-10 2008-09-16 Microsoft Corporation Selective address translation for a resource such as a hardware device
US7881921B1 (en) 2006-07-05 2011-02-01 Synopsys, Inc. Caching information to map simulation addresses to host addresses in computer system simulations
US8019968B2 (en) 2008-02-14 2011-09-13 International Business Machines Corporation 3-dimensional L2/L3 cache array to hide translation (TLB) delays
US8041894B2 (en) 2008-02-25 2011-10-18 International Business Machines Corporation Method and system for a multi-level virtual/real cache system with synonym resolution
US8095773B2 (en) 2008-02-26 2012-01-10 International Business Machines Corporation Dynamic address translation with translation exception qualifier
US7472226B1 (en) 2008-03-20 2008-12-30 International Business Machines Corporation Methods involving memory caches
JP5300407B2 (ja) 2008-10-20 2013-09-25 株式会社東芝 仮想アドレスキャッシュメモリ及び仮想アドレスキャッシュ方法
US8549208B2 (en) 2008-12-08 2013-10-01 Teleputers, Llc Cache memory having enhanced performance and security features
US20100211616A1 (en) 2009-02-16 2010-08-19 Rajesh Khandelwal Performance by Avoiding Disk I/O for Deduplicated File Blocks
WO2010095182A1 (ja) * 2009-02-17 2010-08-26 パナソニック株式会社 マルチスレッドプロセッサ及びデジタルテレビシステム
US8429377B2 (en) 2010-01-08 2013-04-23 International Business Machines Corporation Optimizing TLB entries for mixed page size storage in contiguous memory
WO2013058745A1 (en) 2011-10-18 2013-04-25 Soft Machines, Inc. Methods and systems for managing synonyms in virtually indexed physically tagged caches
US9047194B2 (en) 2012-07-18 2015-06-02 Empire Technology Development Llc Virtual cache directory in multi-processor architectures
US20140082252A1 (en) 2012-09-17 2014-03-20 International Business Machines Corporation Combined Two-Level Cache Directory
GB2507759A (en) 2012-11-08 2014-05-14 Ibm Hierarchical cache with a first level data cache which can access a second level instruction cache or a third level unified cache
CN104252425B (zh) 2013-06-28 2017-07-28 华为技术有限公司 一种指令缓存的管理方法和处理器
GB2516477A (en) 2013-07-24 2015-01-28 Ibm Method and system for handling virtual memory address synonyms in a multi-level cache hierarchy structure
CN105095104B (zh) 2014-04-15 2018-03-27 华为技术有限公司 数据缓存处理方法及装置
CN104679669B (zh) 2014-11-27 2018-04-27 华为技术有限公司 高速缓存cache存储器系统及访问缓存行cache line的方法
US10089240B2 (en) 2014-12-26 2018-10-02 Wisconsin Alumni Research Foundation Cache accessed using virtual addresses
US9477613B2 (en) 2015-02-13 2016-10-25 International Business Machines Corporation Position-based replacement policy for address synonym management in shared caches
CN105095114A (zh) 2015-08-13 2015-11-25 广州优倍达信息科技有限公司 一种计算机缓存系统的管理方法
US20170091117A1 (en) * 2015-09-25 2017-03-30 Qualcomm Incorporated Method and apparatus for cache line deduplication via data matching
GB2543745B (en) 2015-10-15 2018-07-04 Advanced Risc Mach Ltd An apparatus and method for operating a virtually indexed physically tagged cache
CN105677581A (zh) 2016-01-05 2016-06-15 上海斐讯数据通信技术有限公司 一种内存访问装置和方法
US10176099B2 (en) 2016-07-11 2019-01-08 Intel Corporation Using data pattern to mark cache lines as invalid
US10698836B2 (en) 2017-06-16 2020-06-30 International Business Machines Corporation Translation support for a virtual cache
US10606762B2 (en) 2017-06-16 2020-03-31 International Business Machines Corporation Sharing virtual and real translations in a virtual cache
US10831664B2 (en) 2017-06-16 2020-11-10 International Business Machines Corporation Cache structure using a logical directory

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11403222B2 (en) 2017-06-16 2022-08-02 International Business Machines Corporation Cache structure using a logical directory
US11775445B2 (en) 2017-06-16 2023-10-03 International Business Machines Corporation Translation support for a virtual cache

Also Published As

Publication number Publication date
US20180365172A1 (en) 2018-12-20
WO2018229701A1 (en) 2018-12-20
US10831674B2 (en) 2020-11-10
US20230401161A1 (en) 2023-12-14
US11775445B2 (en) 2023-10-03
GB202000046D0 (en) 2020-02-19
GB2577023A (en) 2020-03-11
US20180365170A1 (en) 2018-12-20
US20210026783A1 (en) 2021-01-28
JP2020523676A (ja) 2020-08-06
GB2577023B (en) 2020-08-05
JP7184815B2 (ja) 2022-12-06
US10698836B2 (en) 2020-06-30

Similar Documents

Publication Publication Date Title
DE112018002028T5 (de) Umsetzungsunterstützung für einen virtuellen cache
DE112018002032T5 (de) Gemeinsames nutzen von virtuellen und realen übersetzungen in einem virtuellen cache
DE112013002934B4 (de) Verwalten eines Zugreifens auf Seitentabelleneinträge
DE69637294T2 (de) Mikro-tlb mit parallelem zugriff zum beschleunigen der adressübersetzung
DE112017001027B4 (de) Seitenfehlerbehebung
DE112018003032T5 (de) Cachestruktur, die ein logisches verzeichnis verwendet
CN104516833B (zh) 用于多个顺序地址转换的合并的tlb结构
DE60320026T2 (de) Verbessertes speichermanagement für echtzeit-anwendungen
DE102014014076A1 (de) Reduzierte Adressenkonvertierung mit mehreren Seitengrößen
DE602004011018T2 (de) Ungültigkeitserklärung eines speichers und löschen von puffereinträgen
DE2226382C3 (de) Datenverarbeitungsanlage mit mehreren Prozessoren und diesen zugeordneten Pufferspeichern
DE112005003863B3 (de) Verwalten von Prozessorressourcen während Architekturereignissen
DE4410060B4 (de) Übersetzungsvorrichtung zum Umsetzen einer virtuellen Speicheradresse in eine physikalische Speicheradresse
DE69721590T2 (de) Ein bereichsbasiertes seiten-table-walk-bit verwendendes verfahren sowie vorrichtung
DE2459006C2 (de) Einrichtung zum Bilden einer absoluten Adresse in einer Datenverarbeitunsanlage
DE112013002938B4 (de) Übersetzen der Basistabelle von Speichern
DE112017002941T5 (de) Arbeitslastoptimierte Datendeduplizierung mittels Phantomfingerabdrücken
DE202007019502U1 (de) Globaler Überlauf für virtualisierten Transaktionsspeicher
DE4335475A1 (de) Datenverarbeitungseinrichtung mit Cache-Speicher
DE112013001751T5 (de) Hybride Adressumsetzung
DE10002120A1 (de) Logikstruktur eines Adressumsetzpuffers
DE102020104701A1 (de) Cache data location system
DE112017005014B4 (de) Qualifizieren des Durchsuchens eines Verzweigungsprädiktors unter Verwendung der Vorhersage einer Datenstromlänge
DE102020132140A1 (de) Pipelines für sichere Multithread-Ausführung
DE102021116489A1 (de) Verwaltung von Prefetch-Anfragen auf Basis von Stream-Informationen für zuvor erkannte Streams

Legal Events

Date Code Title Description
R012 Request for examination validly filed