DE102022116706A1 - Fehlereingrenzung zum ermöglichen eines lokalen kontrollpunkts und einer wiederherstellung - Google Patents

Fehlereingrenzung zum ermöglichen eines lokalen kontrollpunkts und einer wiederherstellung Download PDF

Info

Publication number
DE102022116706A1
DE102022116706A1 DE102022116706.2A DE102022116706A DE102022116706A1 DE 102022116706 A1 DE102022116706 A1 DE 102022116706A1 DE 102022116706 A DE102022116706 A DE 102022116706A DE 102022116706 A1 DE102022116706 A1 DE 102022116706A1
Authority
DE
Germany
Prior art keywords
memory
data
client
error
computer
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
DE102022116706.2A
Other languages
English (en)
Inventor
Naveen Cherukuri
Saurabh HUKERIKAR
Paul Racunas
Nirmal Raj Saxena
David Charles PATRICK
Yiyang Feng
Abhijeet Ghadge
Steven James HEINRICH
Adam Hendrickson
Gentaro Hirota
Praveen Joginipally
Vaishali Kulkarni
Peter C. Mills
Sandeep Navada
Manan Patel
Liang Yin
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.)
Nvidia Corp
Original Assignee
Nvidia 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 Nvidia Corp filed Critical Nvidia Corp
Publication of DE102022116706A1 publication Critical patent/DE102022116706A1/de
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1402—Saving, restoring, recovering or retrying
    • G06F11/1415—Saving, restoring, recovering or retrying at system level
    • G06F11/142—Reconfiguring to eliminate the error
    • 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
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/08—Error detection or correction by redundancy in data representation, e.g. by using checking codes
    • G06F11/10—Adding special bits or symbols to the coded information, e.g. parity check, casting out 9's or 11's
    • G06F11/1008—Adding special bits or symbols to the coded information, e.g. parity check, casting out 9's or 11's in individual solid state devices
    • G06F11/1012—Adding special bits or symbols to the coded information, e.g. parity check, casting out 9's or 11's in individual solid state devices using codes or arrangements adapted for a specific type of error
    • G06F11/1016—Error in accessing a memory location, i.e. addressing error
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0706—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment
    • G06F11/073—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment in a memory management context, e.g. virtual memory or cache management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0766—Error or fault reporting or storing
    • G06F11/0772—Means for error signaling, e.g. using interrupts, exception flags, dedicated error registers
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0793—Remedial or corrective actions
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1402—Saving, restoring, recovering or retrying
    • G06F11/1405—Saving, restoring, recovering or retrying at machine instruction level
    • G06F11/1407—Checkpointing the instruction stream
    • 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
    • G06F12/1018—Address translation using page tables, e.g. page table structures involving hashing techniques, e.g. inverted page tables
    • 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]

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Quality & Reliability (AREA)
  • Hardware Redundancy (AREA)
  • Retry When Errors Occur (AREA)

Abstract

Verschiedene Ausführungsformen weisen ein Parallelverarbeitungs-Computersystem auf, das Speicherfehler erkennt, wenn ein Speicher-Client Daten aus einem Speicher lädt, und den Speicher-Client daran hindert, Daten im Speicher zu speichern, wodurch die Wahrscheinlichkeit verringert wird, dass sich der Speicherfehler auf andere Speicher-Clients ausbreitet. Der Speicher-Client leitet eine Haltesequenz ein, während andere Speicher-Clients fortfahren, Befehle auszuführen, und der Speicher fortfährt, Speicher-Lade- und Speicheroperationen zu bedienen. Wenn ein Speicherfehler erkannt wird, wird ein spezielles Bitmuster in Verbindung mit den Daten, die dem Speicherfehler zugeordnet sind, gespeichert. Wenn die Daten von einem Speicher in einen anderen Speicher kopiert werden, wird das spezielle Bitmuster auch kopiert, um die Daten als einen Speicherfehler ausweisend zu identifizieren.

Description

  • HINTERGRUND
  • Gebiet der verschiedenen Ausführungsformen
  • Verschiedene Ausführungsformen betreffen im Allgemeinen Parallelverarbeitungs-Rechenarchitekturen und insbesondere eine Fehlereingrenzung zum Ermöglichen eines lokalen Kontrollpunkts und einer Wiederherstellung.
  • Beschreibung des Standes der Technik
  • Systeme für hohe Rechenleistung (high performance computing, HPC) sind große Computersysteme, die Hunderte oder Tausende von vernetzten Rechenknoten umfassen, die hier als Betriebssystem (operating system, OS) Knoten bezeichnet werden. Jeder OS-Knoten umfasst im Allgemeinen unter anderem eine oder mehrere Verarbeitungseinheiten, wie z. B. zentrale Verarbeitungseinheiten (central processing units, CPUs) und/oder Grafikverarbeitungseinheiten (graphics processing units, GPUs), und ein oder mehrere Speichersysteme. Ein solches HPC-System mit einer großen Anzahl von vernetzten OS-Knoten kann eingesetzt werden, um große Datenmengen zu verarbeiten und komplexe Berechnungen mit Geschwindigkeiten durchzuführen, die von einem einzelnen OS-Knoten unerreichbar sind.
  • Eine Einschränkung von großen HPC-Systemen besteht darin, dass solche Systeme für bestimmte vorübergehende (transiente) Hardwarefehler anfällig sind, die zu einer Beschädigung von Daten führen, die in den Speichersystemen von einem oder mehreren OS-Knoten gespeichert sind. Diese vorübergehenden Hardwarefehler werden hierin als Speicherfehler bezeichnet. Eine solche Art von Speicherfehler tritt auf, wenn ein Teilchen eine Speicherzelle trifft, wodurch der Wert der Speicherzelle von 0 auf 1 oder von 1 auf 0 geändert wird. Dies kann aus hochenergetischen Protonen- und/oder Neutroneneinschlägen aufgrund von kosmischer Strahlung, thermischen Neutronen, Alphateilcheneinschlägen und/oder Ähnlichem resultieren. Diese Art eines Soft Error bleibt so lange bestehen, bis ein anderer Wert in der Speicherzelle gespeichert wird. Ein OS-Knoten, der beschädigte Daten von einem Speicherplatz lädt, kann Berechnungen unter Verwendung der beschädigten Daten durchführen oder die beschädigten Daten als einen Befehl ausführen, was stillschweigend andere Speicherplätze beschädigen kann, d. h. eine solche Beschädigung kann nicht erkennbar sein. Zusätzlich können, wenn der OS-Knoten Daten mit anderen OS-Knoten im HPC-System austauscht, andere OS-Knoten ebenfalls geschädigt werden.
  • Ein Ansatz zum Wiederherstellen nach Speicherfehlern ist, für jede Anwendungssoftware oder Systemsoftware periodisch einen Schnappschuss des Systemzustands, des OS-Knotenzustands und/oder des Anwendungszustands über alle OS-Knoten im HPC-System zu erstellen und den Schnappschuss in einem Dateisystem zu speichern. Dieser Schnappschuss wird hierin als ein globaler Kontrollpunkt bezeichnet. Wenn einer der Betriebssystemknoten einen Speicherfehler feststellt, werden alle Betriebssystemknoten angehalten, der letzte globale Kontrollpunkt in die OS-Knoten geladen, und die OS-Knoten setzen die Ausführung ab dem letzten globalen Kontrollpunkt fort. Ein Nachteil dieses Ansatzes zur Speicherung und Wiederherstellung globaler Kontrollpunkte ist, dass mit zunehmender Anzahl und Größe der OS-Knoten die mittlere Zeit zwischen den Ausfällen abnimmt, während die Zeit, um den globalen Kontrollpunkt zu speichern, ansteigt. Folglich wird mit zunehmender Größe des HPC-Systems mehr Zeit und Rechenleistung zum Speichern globaler Kontrollpunkte verbraucht, und es wird nur ein geringer Fortschritt bei der Ausführung der Anwendungssoftware erzielt, bevor ein Speicherfehler auftritt, was zu einer Wiederherstellung des letzten globalen Kontrollpunkts führt.
  • Eine Verbesserung zum globalen Kontrollpunkt und der Wiederherstellung besteht darin, den globalen Kontrollpunkt und die Wiederherstellung um einen lokalen Kontrollpunkt und eine Wiederherstellung zu erweitern. Bei dem lokalen Kontrollpunkt und der Wiederherstellung wird ein separater lokaler Schnappschuss des Zustands für jeden OS-Knoten oder einen Abschnitt davon in dem HPC-System erstellt, und die Schnappschüsse werden in einem Dateisystem gespeichert. Dieser Snapshot wird hier als lokaler Kontrollpunkt bezeichnet. Wenn einer der OS-Knoten einen Speicherfehler feststellt, wird nur der betroffene OS-Knoten angehalten, der letzte lokale Kontrollpunkt in den OS-Knoten geladen, und der OS-Knoten setzt die Ausführung ab dem letzten lokalen Kontrollpunkt fort. Das Speichern und Laden eines lokalen Kontrollpunkts verbessert typischerweise den Systemdurchsatz und hilft beim Vorwärtskommen der Anwendungssoftware im Verhältnis zu Ansätzen mit globalem Kontrollpunkt und Wiederherstellung. Softwarefehler, die nicht mittels lokalem Kontrollpunkt und Wiederherstellung gelöst werden können, können immer noch mittels globalem Kontrollpunkt und Wiederherstellung gelöst werden.
  • In einem Beispiel können die Leistungskosten eines Fehlers eine Stunde Durchsatzverlust pro Knoten in einem HPC-System betragen, das 1000 Knoten aufweist und eine mittlere Zeit zwischen zwei Fehlern (mean time between failure, MTBF) von 1000 Stunden pro Knoten aufweist. In einem solchen HPC-System wird erwartet, dass jeder Knoten im Durchschnitt alle 1000 Stunden einen Fehler erfährt. Das HPC-System ist mit einem Anwendungssoftwareprogramm beauflagt, wobei der gesamte Auftrag für 10.000 Stunden ausgeführt wird. Im Falle eines globalen Kontrollpunkts und einer Wiederherstellung bewirkt ein Ausfall eines beliebigen Knotens, dass der globale Kontrollpunkt wiederherzustellen ist. Bei einem MTBF von 1000 Stunden pro Knoten und einem HPC-System, das 1000 Knoten aufweist, erfährt das HPC-System durchschnittlich einen Fehler pro Stunde. Daher stellen die Knoten im Laufe jeder Stunde den globalen Kontrollpunkt wieder her und verlieren eine Stunde der Arbeit. Selbst wenn nur ein Knoten einen Fehler erfährt, werden alle Knoten beeinträchtigt. Im schlimmsten Fall macht das HPC-System keine Fortschritte, weil das Anwendungssoftwareprogramm eine Stunde lang ausgeführt wird, dann ereignet sich auf einem oder mehreren Knoten ein Fehler, und alle Knoten kehren zu dem letzten globalen Kontrollpunkt zurück, der den Beginn des Anwendungssoftwareprogramms darstellt. Im Gegensatz dazu treten bei einem lokalen Kontrollpunkt im Durchschnitt auf jedem Knoten 10 Fehler während der Ausführungszeit des Auftrags auf, bei einer Ausführungszeit von 10.000 Stunden und einer MTBF von 1000 Stunden. Als Ergebnis verzeichnet jeder Knoten unabhängig 10 Stunden verlorenen Durchsatz, was insgesamt 10.010 Stunden Ausführungszeit für jeden Knoten ergibt.
  • Ein Nachteil dieses Ansatzes für eine Speicherung und Wiederherstellung eines lokalen Kontrollpunkts besteht darin, dass lokale Kontrollpunkt- und Wiederherstellungstechniken für eine GPU typischerweise Kontrollpunkte unter Verwendung von Code speichern und wiederherstellen, der auf der CPU ausgeführt wird. Dies hat zur Folge, dass Kontrollpunkte zwischen GPU-Kernel-Starts erfasst und gespeichert werden, wobei ein Kernel viele Stunden lang ausgeführt werden kann. Die lokale Wiederherstellung von Kontrollpunkten auf der CPU beschränkt die CPU auf eine Prüfung auf Fehler, nachdem der Kernel die Ausführung auf der GPU abgeschlossen hat. Ein lokaler Kontrollpunkt und eine Wiederherstellung können pro N Kernel durchgeführt werden, wobei N eine beliebige Zahl größer oder gleich 1 sein kann. Wird ein Fehler erfasst, wird der betroffene Kernel lokal wiederhergestellt. Andere CPUs und GPUs in dem System sind nicht betroffen. Während der Ausführung des betroffenen Kernels kann die GPU jedoch von dem Zeitpunkt, an dem der Fehler auftrat, bis zu dem Zeitpunkt, an dem der lokale Kontrollpunkt wiederhergestellt wird, einen beschädigten Zustand aufweisen. Ferner kann sich die Fehlerhaftigkeit eines Kernels, der auf einer GPU ausgeführt wird, negativ auf andere GPUs auswirken, z. B. wenn eine GPU, die einen fehlerhaften Kernel ausführt, mit anderen GPUs in Verbindung steht.
  • Eine Möglichkeit, eine Verfälschung zwischen den GPUs zu vermeiden, besteht darin, ein System zu bauen, bei dem die GPUs über die CPU kommunizieren, anstatt direkt miteinander zu sprechen. Dieser Ansatz schränkt jedoch einen wesentlichen Vorteil von HPC-Systemen ein, da eine Kommunikation von GPU zu GPU typischerweise eine höhere Bandbreite im Vergleich zu einer Kommunikation von GPU zu CPU aufweist. Weiterhin, wenn die GPU nicht über eine Fähigkeit zur Fehlereingrenzung verfügt, kann eine GPU den CPU-Zustand verfälschen, ohne entdeckt zu werden, z. B. wenn eine GPU verfälschte Daten verwendet, um den von der CPU verwendeten Speicher zu aktualisieren. Ohne Fehlereingrenzung auf der GPU ist nicht gewährleistet, dass ein lokaler Kontrollpunkt und eine Wiederherstellung korrekte Ergebnisse liefern. In Anbetracht dieser Einschränkungen eines lokalen Kontrollpunkts und einer Wiederherstellung erfordert die Aufrechterhaltung der Integrität einer gemeinsamen Nutzung von CPU und GPU oder einer gemeinsamen Nutzung zwischen GPUs typischerweise entweder eine Verwendung eines globalen Kontrollpunkts und einer Wiederherstellung, was zu einem geringeren Durchsatz oder keinem Fortschritt führt, oder einen Aufbau kleinerer, weniger leistungsfähiger HPC-Systeme mit einer längeren MTBF.
  • Wie das Vorstehende veranschaulicht, werden in der Technik effektivere Techniken zur Wiederherstellung nach Speicherfehlern in großen Rechensystemen benötigt.
  • ZUSAMMENFASSUNG
  • Verschiedene Ausführungsformen der vorliegenden Offenbarung legen ein computerimplementiertes Verfahren zum Verarbeiten eines Speicherfehlers dar. Das Verfahren beinhaltet ein Bewirken, dass ein erster Befehl, der eine erste Speicher-Ladeoperation aufweist, von einem ersten Speicher-Client ausgeführt wird, der in mehreren Speicher-Clients enthalten ist. Das Verfahren umfasst ferner ein Empfangen eines Hinweises, dass Daten, die der Speicher-Ladeoperation zugeordnet sind, beschädigt sind. Das Verfahren weist ferner als Reaktion auf ein Empfangen des Hinweises auf: (1) Sperren des ersten Speicher-Clients für ein Durchführen von Speicher-Einspeicheroperationen, und (2) Einleiten einer oder mehrerer Halteoperationen für den ersten Speicher-Client. Ferner fährt ein zweiter Speicher-Client, der in den mehreren Speicher-Clients enthalten ist, mit der Ausführung von Befehlen fort, während der erste Speicher-Client gesperrt ist.
  • Andere Ausführungsformen weisen ohne Einschränkung ein System, das einen oder mehrere Aspekte der offenbarten Techniken implementiert, und ein oder mehrere computerlesbare Medien, die Befehle zur Ausführung eines oder mehrerer Aspekte der offenbarten Techniken enthalten, sowie ein Verfahren zum Ausführen eines oder mehrerer Aspekte der offenbarten Techniken auf.
  • Mindestens ein technischer Vorteil der offenbarten Techniken im Vergleich zu dem Stand der Technik besteht darin, dass mit den offenbarten Techniken ein lokaler Kontrollpunkt und eine Wiederherstellung mit einer feineren Granularität im Vergleich zu früheren Ansätzen ausgeführt wird. Wenn ein Speicher-Client innerhalb einer GPU einen Speicherfehler feststellt, wird nur der betroffene Speicher-Client angehalten, der letzte lokale Kontrollpunkt wird in den Speicher-Client geladen, und der Speicher-Client setzt die Ausführung ab dem letzten lokalen Kontrollpunkt fort. Ferner werden der lokale Kontrollpunkt und die Wiederherstellung von der GPU und für jeden Speicher-Client durchgeführt, was zu einer schnelleren Erkennung von Speicherfehlern, die während der Ausführung des GPU-Programms auftreten, führt. Ein weiterer technischer Vorteil der offenbarten Techniken ist, dass, wenn ein Speicher-Client innerhalb der GPU einen Speicherfehler feststellt, der Speicher-Client daran gehindert wird, Daten zu speichern oder anderweitig an andere Speicherplätze, andere Speicher-Clients in der GPU, andere GPUs oder die CPU zu übertragen. Infolgedessen wird die Möglichkeit, dass sich ein in einer GPU auftretender Speicherfehler auf andere Teile des OS-Knotens oder auf andere OS-Knoten ausbreitet, im Vergleich zu früheren Ansätzen verringert. Diese Vorteile stellen eine oder mehrere technologische Verbesserungen gegenüber Ansätzen nach dem Stand der Technik dar.
  • Figurenliste
  • Damit die Art und Weise der oben genannten Merkmale der verschiedenen Ausführungsformen im Detail verstanden werden können, wird eine genauere Beschreibung der erfinderischen Konzepte, die oben kurz zusammengefasst wurden, durch Bezugnahme auf verschiedene Ausführungsformen, von denen einige in den beigefügten Zeichnungen dargestellt sind, erfolgen. Es ist jedoch zu beachten, dass die beigefügten Zeichnungen nur typische Ausführungsformen der erfindungsgemäßen Konzepte zeigen und daher in keiner Weise als Einschränkung des Umfangs anzusehen sind, und dass es andere, gleichermaßen wirksame Ausführungsformen gibt.
    • 1 ist ein Blockdiagramm eines Computersystems, das ausgestaltet ist, um einen oder mehrere Aspekte der verschiedenen Ausführungsformen zu implementieren;
    • 2 ist ein Blockdiagramm einer Parallelverarbeitungseinheit (PPU), die in dem Parallelverarbeitungssubsystem von 1 enthalten ist, gemäß verschiedener Ausführungsformen;
    • 3 ist ein Blockdiagramm eines allgemeinen Verarbeitungsclusters (GPC), der in der Parallelverarbeitungseinheit (PPU) von 2 enthalten ist, gemäß verschiedener Ausführungsformen;
    • 4 ist ein Blockdiagramm des Speicherzugriffssystems, das in der PPU und dem GPC von 2 enthalten ist, gemäß verschiedener Ausführungsformen;
    • 5 ist ein Ablaufdiagramm von Verfahrensschritten zum Speichern lokaler Kontrollpunkte mittels der PPU von 2, gemäß verschiedener Ausführungsformen;
    • 6 ist ein Ablaufdiagramm von Verfahrensschritten zum Verarbeiten eines Speicherfehlers mittels der PPU von 2, gemäß verschiedener Ausführungsformen; und
    • 7 ist ein Ablaufdiagramm von Verfahrensschritten zum Auslagern einer Cache-Zeile, die einen Speicherfehler enthält, gemäß verschiedener Ausführungsformen.
  • DETAILLIERTE BESCHREIBUNG
  • In der folgenden Beschreibung werden zahlreiche spezifische Details dargelegt, um ein umfassenderes Verständnis der verschiedenen Ausführungsformen zu vermitteln. Einem Fachmann wird jedoch klar sein, dass die erfindungsgemäßen Konzepte auch ohne eines oder mehrere dieser spezifischen Details ausgeführt werden können.
  • Wie hierin beschrieben, führt eine GPU feingranulare lokale Kontrollpunkte und Wiederherstellung an Befehlsgrenzen von Speicher-Clients innerhalb der GPU aus. Infolgedessen speichern die beschriebenen Techniken den Mikroarchitektur-Status an feineren Grenzen im Vergleich zu früheren Techniken, die einen Kontrollpunkt und eine Wiederherstellung des Anwendungszustands an Kernel- oder Funktionsgrenzen durchführen. Wie hierin definiert, umfasst ein Speicher-Client eine beliebige Komponente, die Befehle ausführt und/oder andere Operationen durchführt, die Daten aus dem Speicher laden und/oder Daten im Speicher speichern. Ein Software-Wiederherstellungstreiber speichert regelmäßig den Mikroarchitektur-Status als lokale Kontrollpunkte für die Speicher-Clients in der GPU. Genauer gesagt nutzt der Software-Wiederherstellungstreiber die Funktion zum Berechnen einer Unterbrechung auf Befehlsebene (Compute Instruction Level Preemption, CILP) der GPU, um die Ausführung an einer GPU-Programmbefehlsgrenze anzuhalten. Wenn die Speicher-Clients innerhalb der GPU angehalten wurden, speichert der Software-Wiederherstellungstreiber einen Kontrollpunkt, der den Mikroarchitektur-Status der Speicher-Clients enthält. Wie hierin weiter beschrieben, umfasst ein Speicher-Client eine beliebige Systemkomponente, die Speicher-Ladeoperationen und/oder Speicher-Einspeicheroperationen in einem beliebigen Speicher durchführt. Speicher-Clients umfassen ohne Einschränkung Streaming-Multiprozessoren (SMs), globale Konstant-Caches (global constant caches GCCs), Kopiermaschinen (copy engines) 434, Kontextwechsler (context switchers) und/oder dergleichen. Wenn ein Speicher-Client einen Speicherfehler erfasst, verhindert der Speicher-Client, dass weitere Daten von dem Speicher-Client gespeichert oder an das Speichersystem übertragen werden, wodurch verhindert wird, dass sich der Speicherfehler auf andere Speicher-Clients, andere GPUs oder die CPU ausbreitet. Der Speicher-Client blockiert ferner Kontextwechsel und Speicherbarrieren (memory barriers), um den Speicherfehler einzudämmen. Der Speicher-Client initiiert eine oder mehrere Halteoperationen, um Befehle aus beliebigen Befehlswarteschlangen im Speicher-Client auszulagern, um alle anstehenden Speicheroperationen zu entfernen. Als Ergebnis bewahrt der Speicher-Client die Integrität des vorhergehenden lokalen Kontrollpunkts und ermöglicht so dem Software-Wiederherstellungstreiber einen zuverlässigen Neustart ab dem vorhergehenden lokalen Kontrollpunkt. Der Speicher-Client speichert Fehlerprotokolldaten, die Daten enthalten, die dem Speicherfehler zugeordnet sind, benachrichtigt den Software-Wiederherstellungstreiber und hält an. Der Software-Wiederherstellungstreiber greift dann auf die Fehlerprotokolldaten zu, um die Art des Speicherfehlers zu ermitteln, stellt den vorhergehenden lokalen Kontrollpunkt wieder her und startet den angehaltenen Speicher-Client neu.
  • System-Übersicht
  • 1 ist ein Blockdiagramm eines Computersystems 100, das ausgebildet ist, um einen oder mehrere Aspekte der verschiedenen Ausführungsformen zu implementieren. Wie gezeigt, umfasst das Computersystem 100 ohne Einschränkung eine Zentraleinheit (central processing unit, CPU) 102 und einen Systemspeicher 104, der über eine Speicherbrücke 105 und einen Kommunikationspfad 113 mit einem Parallelverarbeitungssubsystem 112 gekoppelt ist. Die Speicherbrücke 105 ist ferner über einen Kommunikationspfad 106 mit einer E/A(Eingabe/Ausgabe)-Brücke 107 gekoppelt, und die E/A-Brücke 107 ist ihrerseits mit einem Schalter (switch) 116 gekoppelt.
  • Im Betrieb ist die E/A-Brücke 107 ausgestaltet, um Benutzereingabeinformationen von Eingabevorrichtungen 108, wie z. B. einer Tastatur oder einer Maus, zu empfangen und die Eingabeinformationen für eine Verarbeitung über den Kommunikationspfad 106 und die Speicherbrücke 105 an die CPU 102 weiterzuleiten. Der Schalter 116 ist ausgestaltet, um Verbindungen zwischen der E/A-Brücke 107 und anderen Komponenten des Computersystems 100 bereitzustellen, wie z. B. einem Netzwerkadapter 118 und verschiedenen Zusatzkarten 120 und 121.
  • Wie auch gezeigt, ist die E/A-Brücke 107 mit einer Systemdisk 114 gekoppelt, die ausgestaltet sein kann, um Inhalte, Anwendungen und Daten für eine Verwendung durch die CPU 102 und das Parallelverarbeitungssubsystem 112 zu speichern. Grundsätzlich stellt die Systemdisk 114 einen nichtflüchtigen Speicher für Anwendungen und Daten bereit und kann feste oder entfernbare Festplattenlaufwerke, Flash-Speichervorrichtungen und CD-ROM (Compact Disc Read-Only-Memory), DVD-ROM (Digital Versatile Disc-ROM), Blu-ray, HD-DVD (High Definition DVD) oder andere magnetische, optische oder Festkörperspeichervorrichtungen aufweisen. Schließlich, obwohl nicht explizit gezeigt, können auch andere Komponenten, wie ein Universal Serial Bus oder andere Anschlussverbindungen, Compact-Disc-Laufwerke, Digital Versatile Disc-Laufwerke, Filmaufzeichnungsgeräte und dergleichen, an die E/A-Brücke 107 angeschlossen werden.
  • In verschiedenen Ausführungsformen kann die Speicherbrücke 105 ein Northbridge-Chip und die E/A-Brücke 107 ein Southbridge-Chip sein. Darüber hinaus können die Kommunikationspfade 106 und 113 sowie andere Kommunikationspfade innerhalb des Computersystems 100 unter Verwendung beliebiger technisch geeigneter Protokolle implementiert werden, einschließlich, aber nicht beschränkt auf AGP (Accelerated Graphics Port), HyperTransport oder jedes andere Bus- oder Punkt-zu-Punkt-Kommunikationsprotokoll, das in der Technik bekannt ist.
  • In einigen Ausführungsformen umfasst das Parallelverarbeitungssubsystem 112 ein Grafiksubsystem, das Bildpunkte an eine Anzeigevorrichtung 110 liefert, die eine herkömmliche Kathodenstrahlröhre, Flüssigkristallanzeige, Leuchtdiodenanzeige oder Ähnliches sein kann. In solchen Ausführungsformen beinhaltet das Parallelverarbeitungssubsystem 112 Schaltungen, die für die Grafik- und Videoverarbeitung optimiert sind, welche z. B. Videoausgangsschaltungen aufweisen. Wie in 2 nachfolgend näher beschrieben, können solche Schaltungen in einer oder mehreren Parallelverarbeitungseinheiten (parallel processing units, PPUs), welche in dem Parallelverarbeitungssubsystem 112 enthalten sind, enthalten sein. In anderen Ausführungsformen enthält das Parallelverarbeitungssubsystem 112 Schaltungen, die für die allgemeine und/oder die Rechenverarbeitung optimiert sind. Wiederum kann eine solche Schaltung in eine oder mehrere PPUs, die in dem Parallelverarbeitungssubsystem 112 enthalten sind, eingebaut sein, die ausgestaltet sind, um solche Allzweck- und/oder Rechenoperationen durchzuführen. In noch anderen Ausführungsformen können die eine oder die mehreren PPUs, die im Parallelverarbeitungssubsystem 112 enthalten sind, ausgestaltet sein, um Grafikverarbeitungs-, Allzweckverarbeitungs- und Rechenverarbeitungsoperationen durchzuführen. Der Systemspeicher 104 weist mindestens einen Gerätetreiber 103 auf, der ausgestaltet ist, um die Verarbeitungsvorgänge der einen oder mehreren PPUs innerhalb des Parallelverarbeitungssubsystems 112 zu verwalten.
  • In verschiedenen Ausführungsformen kann das Parallelverarbeitungssubsystem 112 mit einem oder mehreren anderen Elementen der 1 integriert werden, um ein einziges System zu bilden. Zum Beispiel kann das Parallelverarbeitungssubsystem 112 mit der CPU 102 und anderen Verbindungsschaltungen auf einem einzigen Chip integriert werden, um ein System on Chip (SoC) zu bilden.
  • Es wird deutlich, dass das hier gezeigte System veranschaulichend ist und dass Veränderungen und Modifikationen möglich sind. Die Verbindungstopologie, einschließlich der Anzahl und Anordnung der Brücken, der Anzahl der CPUs 102 und der Anzahl der Parallelverarbeitungssubsysteme 112, kann nach Belieben geändert werden. Zum Beispiel kann in einigen Ausführungsformen der Systemspeicher 104 direkt statt über die Speicherbrücke 105 mit der CPU 102 verbunden werden, und andere Vorrichtungen würden über die Speicherbrücke 105 und die CPU 102 mit dem Systemspeicher 104 kommunizieren. In anderen alternativen Topologien kann das Parallelverarbeitungssubsystem 112 mit der E/A-Brücke 107 oder direkt mit der CPU 102 statt mit der Speicherbrücke 105 verbunden sein. In noch anderen Ausführungsformen können die E/A-Brücke 107 und die Speicherbrücke 105 in einen einzigen Chip integriert werden, anstatt als eine oder mehrere diskrete Vorrichtungen zu existieren. Schließlich können in bestimmten Ausführungsformen eine oder mehrere der in 1 gezeigten Komponenten nicht vorhanden sein. Zum Beispiel könnte der Schalter 116 entfallen, und der Netzwerkadapter 118 und die Zusatzkarten 120, 121 würden direkt an die I/O-Brücke 107 angeschlossen.
  • 2 ist ein Blockdiagramm einer Parallelverarbeitungseinheit (PPU) 202, die im Parallelverarbeitungssubsystem 112 von 1 enthalten ist, gemäß verschiedener Ausführungsformen. Obwohl 2 eine PPU 202 zeigt, kann das Parallelverarbeitungssubsystem 112, wie oben erwähnt, eine beliebige Anzahl von PPUs 202 enthalten. Wie gezeigt, ist die PPU 202 mit einem lokalen Parallelverarbeitungs(parallel processing, PP)-Speicher 204 verbunden. Die PPU 202 und der PP-Speicher 204 können unter Verwendung einer oder mehrerer integrierter Schaltkreisvorrichtungen, wie z. B. programmierbarer Prozessoren, anwendungsspezifischer integrierter Schaltkreise (ASICs) oder Speichervorrichtungen, oder auf jede andere technisch ausführbare Weise implementiert werden.
  • In einigen Ausführungsformen umfasst die PPU 202 eine Grafikverarbeitungseinheit (GPU), die ausgestaltet sein kann, um eine Grafik-Rendering-Pipeline zu implementieren, um verschiedene Operationen im Zusammenhang mit der Erzeugung von Bildpunktdaten auf der Grundlage der von der CPU 102 und/oder dem Systemspeicher 104 gelieferten Grafikdaten durchzuführen. Wenn Grafikdaten verarbeitet werden, kann der PP-Speicher 204 als Grafikspeicher verwendet werden, der einen oder mehrere herkömmliche Bildpuffer und, falls erforderlich, auch ein oder mehrere andere Rendering-Ziele speichert. Der PP-Speicher 204 kann unter anderem verwendet werden, um die Bildpunktdaten zu speichern und zu aktualisieren und die endgültigen Bildpunktdaten oder Anzeigerahmen an die Anzeigevorrichtung 110 für eine Anzeige zu liefern. In einigen Ausführungsformen kann die PPU 202 auch für allgemeine Verarbeitungs- und Rechenoperationen ausgestaltet sein.
  • Im Betrieb ist die CPU 102 der Hauptprozessor des Computersystems 100, der die Operationen der anderen Systemkomponenten steuert und koordiniert. Insbesondere gibt die CPU 102 Befehle aus, die den Betrieb der PPU 202 steuern. In einigen Ausführungsformen schreibt die CPU 102 einen Strom von Befehlen für die PPU 202 in eine Datenstruktur (weder in 1 noch in 2 explizit dargestellt), die in dem Systemspeicher 104, dem PP-Speicher 204 oder einem anderen Speicherort liegen kann, der sowohl von der CPU 102 als auch von der PPU 202 zugreifbar ist. Ein Zeiger auf die Datenstruktur wird in einen Push-Puffer geschrieben, um eine Verarbeitung des Stroms von Befehlen in der Datenstruktur einzuleiten. Die PPU 202 liest die Befehlsströme aus dem Push-Puffer und führt die Befehle dann asynchron in Bezug auf den Betrieb der CPU 102 aus. In Ausführungsformen, in denen mehrere Push-Puffer erzeugt werden, können Ausführungsprioritäten für jeden Push-Puffer durch ein Anwendungsprogramm über den Gerätetreiber 103 festgelegt werden, um die zeitliche Planung der verschiedenen Push-Puffer zu steuern.
  • Wie auch gezeigt, weist die PPU 202 eine E/A(Eingabe/Ausgabe)-Einheit 205 auf, die mit dem Rest des Computersystems 100 über den Kommunikationspfad 113 und die Speicherbrücke 105 kommuniziert. Die E/A-Einheit 205 erzeugt Pakete (oder andere Signale) für eine Übertragung auf dem Kommunikationspfad 113 und empfängt auch alle eingehenden Pakete (oder andere Signale) von dem Kommunikationspfad 113, wobei die eingehenden Pakete an geeignete Komponenten der PPU 202 weitergeleitet werden. Beispielsweise können Befehle, die sich auf Verarbeitungsaufgaben beziehen, an eine Host-Schnittstelle 206 geleitet werden, während Befehle, die sich auf Speicheroperationen beziehen (z. B. Lesen von oder Schreiben in den PP-Speicher 204), an eine Kreuzschieneneinheit 210 geleitet werden können. Die Host-Schnittstelle 206 liest jeden Push-Puffer und überträgt den in dem Push-Puffer gespeicherten Befehlsstrom an ein Frontend 212.
  • Wie oben in Verbindung mit 1 erwähnt, kann die Verbindung der PPU 202 mit dem Rest des Computersystems 100 verändert werden. In einigen Ausführungsformen ist das Parallelverarbeitungssubsystem 112, das mindestens eine PPU 202 enthält, als Zusatzkarte implementiert, die in einen Erweiterungssteckplatz des Computersystems 100 eingesetzt werden kann. In anderen Ausführungsformen kann die PPU 202 auf einem einzigen Chip mit einer Busbrücke, wie der Speicherbrücke 105 oder der E/A-Brücke 107, integriert sein. Wiederum in noch anderen Ausführungsformen können einige oder alle Elemente der PPU 202 zusammen mit der CPU 102 in einem einzigen integrierten Schaltkreis oder System on Chip (SoC) enthalten sein.
  • Im Betrieb überträgt das Frontend 212 die von der Host-Schnittstelle 206 empfangenen Verarbeitungsaufgaben an eine Arbeitsverteilungseinheit (nicht dargestellt) innerhalb einer Aufgaben-/Arbeitseinheit 207. Die Arbeitsverteilungseinheit empfängt Zeiger auf Verarbeitungsaufgaben, die als Aufgabenmetadaten (task metadata, TMD) kodiert und im Speicher abgelegt sind. Die Zeiger auf die TMD sind in einem Befehlsstrom enthalten, der als Push-Puffer gespeichert ist und von der Frontend-Einheit 212 von der Host-Schnittstelle 206 empfangen wird. Verarbeitungsaufgaben, die als TMD kodiert werden können, weisen Indizes auf, die den zu verarbeitenden Daten zugeordnet sind, sowie Zustandsparameter und Befehle, die festlegen, wie die Daten zu verarbeiten sind. Zum Beispiel können die Zustandsparameter und Befehle das Programm definieren, das auf den Daten ausgeführt werden soll. Die Aufgaben-/Arbeitseinheit 207 empfängt Aufgaben von dem Frontend 212 und stellt sicher, dass die GPCs 208 auf einen gültigen Zustand konfiguriert sind, bevor die von jeweiligen Daten der TMD angegebene Verarbeitungsaufgabe eingeleitet wird. Für jeweilige Daten der TMD kann eine Priorität festgelegt werden, die zur zeitlichen Planung der Ausführung der Verarbeitungsaufgabe verwendet wird. Verarbeitungsaufgaben können auch von der Verarbeitungsclusteranordnung 230 empfangen werden. Optional können die TMD einen Parameter enthalten, der steuert, ob die TMD dem Anfang oder dem Ende einer Liste von Verarbeitungsaufgaben (oder einer Liste von Zeigern auf die Verarbeitungsaufgaben) hinzugefügt werden, wodurch eine weitere Ebene der Steuerung der Ausführungspriorität bereitgestellt wird.
  • Die PPU 202 implementiert vorteilhafterweise eine hochparallele Verarbeitungsarchitektur, die auf einer Verarbeitungsclusteranordnung 230 basiert, die einen Satz von C allgemeinen Verarbeitungsclustern (general processing clusters, GPCs) 208 umfasst, wobei C >_ 1. Jeder GPC 208 ist in der Lage, eine große Anzahl (z. B. Hunderte oder Tausende) von Threads gleichzeitig auszuführen, wobei jeder Thread eine Instanz eines Programms ist. In verschiedenen Anwendungen können unterschiedliche GPCs 208 für ein Verarbeiten unterschiedlicher Arten von Programmen oder für ein Ausführen unterschiedlicher Arten von Berechnungen zugeordnet werden. Die Zuordnung von GPCs 208 kann in Abhängigkeit von der Arbeitslast variieren, die für jeden Typ von Programmen oder Berechnungen entsteht.
  • Eine Speicherschnittstelle 214 weist einen Satz von D Partitionseinheiten 215 auf, wobei D >_ 1 ist. Jede Partitionseinheit 215 ist mit einem oder mehreren dynamischen Direktzugriffsspeichern (dynamic random access memories, DRAMs) 220 verbunden, die sich in dem PP-Speicher 204 befinden. In einer Ausführungsform ist die Anzahl der Partitionseinheiten 215 gleich der Anzahl der DRAMs 220, und jede Partitionseinheit 215 ist mit einem anderen DRAM 220 verbunden. In anderen Ausführungsformen kann die Anzahl der Partitionseinheiten 215 anders als die Anzahl der DRAMs 220 sein. Fachleute werden verstehen, dass ein DRAM 220 durch jede andere technisch geeignete Speichervorrichtung ersetzt werden kann. Im Betrieb können verschiedene Rendering-Ziele, wie z. B. Texturabbildungen und Bildpuffer, in den DRAMs 220 gespeichert werden, was es den Partitionseinheiten 215 ermöglicht, Teile jedes Rendering-Ziels parallel zu schreiben, um die verfügbare Bandbreite des PP-Speichers 204 effizient zu nutzen.
  • Ein gegebener GPC 208 kann Daten verarbeiten, die in einen beliebigen der DRAMs 220 innerhalb des PP-Speichers 204 geschrieben werden sollen. Die Kreuzschieneneinheit 210 ist ausgestaltet, um die Ausgabe jedes GPC 208 an den Eingang einer beliebigen Partitionseinheit 215 oder an einen beliebigen anderen GPC 208 zur weiteren Verarbeitung weiterzuleiten. Die GPCs 208 kommunizieren über die Kreuzschieneneinheit 210 mit der Speicherschnittstelle 214, um aus verschiedenen DRAMs 220 zu lesen oder in sie zu schreiben. In einer Ausführungsform hat die Kreuzschieneneinheit 210 eine Verbindung zu der E/A-Einheit 205, zusätzlich zu einer Verbindung zu dem PP-Speicher 204 über die Speicherschnittstelle 214, wodurch den Verarbeitungskernen innerhalb der verschiedenen GPCs 208 ermöglicht wird, mit dem Systemspeicher 104 oder einem anderen, nicht lokal bei der PPU 202 befindlichen Speicher zu kommunizieren. In der Ausführungsform von 2 ist die Kreuzschieneneinheit 210 direkt mit der E/A-Einheit 205 verbunden. In verschiedenen Ausführungsformen kann die Kreuzschieneneinheit 210 virtuelle Kanäle verwenden, um Verkehrsströme zwischen den GPCs 208 und den Partitionseinheiten 215 zu trennen. In verschiedenen Ausführungsformen kann die Kreuzschieneneinheit 210 durch eine beliebige Netzwerktopologie ersetzt oder erweitert werden, einschließlich, ohne Einschränkung, eines On-Chip-Netzes.
  • GPCs 208 können wiederum programmiert werden, um Verarbeitungsaufgaben auszuführen, die sich auf eine breite Vielfalt von Anwendungen beziehen, einschließlich, ohne Einschränkung, linearer und nichtlinearer Datentransformationen, Filterung von Video- und/oder Audiodaten, Modellierungsoperationen (z. B. Anwendung physikalischer Gesetze, um Position, Geschwindigkeit und andere Attribute von Objekten zu bestimmen), Bildwiedergabeoperationen (z. B. Tessellation-Shader-, Vertex-Shader-, Geometrie-Shader- und/oder Pixel-/Fragment-Shader-Programme), allgemeine Berechnungsoperationen usw. Im Betrieb ist die PPU 202 ausgestaltet, um Daten aus dem Systemspeicher 104 und/oder dem PP-Speicher 204 an eine oder mehrere On-Chip-Speichereinheiten zu übertragen, die Daten zu verarbeiten und Ergebnisdaten zurück in den Systemspeicher 104 und/oder den PP-Speicher 204 zu schreiben. Auf die Ergebnisdaten kann dann von anderen Systemkomponenten zugegriffen werden, einschließlich der CPU 102, einer anderen PPU 202 innerhalb des Parallelverarbeitungssubsystems 112 oder eines anderen Parallelverarbeitungssubsystems 112 innerhalb des Computersystems 100.
  • Wie oben erwähnt, kann eine beliebige Anzahl von PPUs 202 in einem Parallelverarbeitungssubsystem 112 enthalten sein. Zum Beispiel können mehrere PPUs 202 auf einer einzigen Zusatzkarte bereitgestellt werden, oder mehrere Zusatzkarten können mit dem Kommunikationspfad 113 verbunden werden, oder eine oder mehrere der PPUs 202 können in einen Brückenchip integriert werden. Die PPUs 202 in einem Multi-PPU-System können identisch sein oder sich voneinander unterscheiden. Zum Beispiel können verschiedene PPUs 202 eine unterschiedliche Anzahl von Verarbeitungskernen und/oder unterschiedliche Mengen an PP-Speicher 204 aufweisen. In Implementierungen, in denen mehrere PPUs 202 vorhanden sind, können diese PPUs parallel betrieben werden, um Daten mit einem höheren Durchsatz zu verarbeiten, als dies mit einer einzelnen PPU 202 möglich ist. Systeme, die eine oder mehrere PPUs 202 enthalten, können in einer Vielzahl von Konfigurationen und Formfaktoren implementiert werden, einschließlich, ohne Einschränkung, Desktops, Laptops, tragbare Personal Computer oder andere tragbare Vorrichtungen, Server, Workstations, Spielkonsolen, eingebettete Systeme und dergleichen.
  • 3 ist ein Blockdiagramm eines allgemeinen Verarbeitungsclusters (GPC) 208, der in der Parallelverarbeitungseinheit (PPU) 202 von 2 enthalten ist, gemäß verschiedener Ausführungsformen. Im Betrieb kann der GPC 208 ausgestaltet sein, eine große Anzahl von Threads parallel auszuführen, um Grafik-, allgemeine Verarbeitungs- und/oder Rechenoperationen durchzuführen. Wie hierin verwendet, betrifft ein „Thread“ eine Instanz eines bestimmten Programms, das auf einem bestimmten Satz von Eingangsdaten ausgeführt wird. In einigen Ausführungsformen werden Techniken zur Ausgabe von einzelnen Befehlen für mehrere Daten (single instruction multiple data, SIMD) verwendet, um die parallele Ausführung einer großen Anzahl von Threads zu unterstützen, ohne mehrere unabhängige Befehlseinheiten bereitzustellen. In anderen Ausführungsformen werden Techniken für einzelne Befehle für mehrere Threads (single instruction multiple thread, SIMT) verwendet, um die parallele Ausführung einer großen Anzahl von im Wesentlichen synchronisierten Threads zu unterstützen, wobei eine gemeinsame Befehlseinheit verwendet wird, die ausgestaltet ist, um Befehle an eine Reihe von Verarbeitungsmaschinen innerhalb des GPC 208 auszugeben. Im Unterschied zu einer SIMD-Ausführung, bei der alle Verarbeitungseinheiten typischerweise identische Befehle ausführen, ermöglicht die SIMT-Ausführung, dass verschiedene Threads leichter voneinander abweichenden Ausführungspfaden durch ein bestimmtes Programm folgen können. Fachleute werden verstehen, dass ein SIMD-Verarbeitungsregime eine funktionale Teilmenge eines SIMT-Verarbeitungsregimes darstellt.
  • Der Betrieb des GPC 208 wird über einen Pipeline-Manager 305 gesteuert, der die von einer (nicht dargestellten) Arbeitsverteilungseinheit innerhalb der Aufgaben-/Arbeitseinheit 207 empfangenen Verarbeitungsaufgaben an einen oder mehrere Streaming-Multiprozessoren (SMs) 310 verteilt. Der Pipeline-Manager 305 kann auch ausgestaltet sein, um eine Arbeitsverteilungs-Kreuzschiene 330 zu steuern, indem Ziele für verarbeitete Daten, welche von den SMs 310 ausgegeben werden, angegeben werden.
  • In einer Ausführungsform weist der GPC 208 einen Satz von M SMs 310 auf, wobei M ≥ 1 ist. Ferner weist jeder SM 310 einen Satz funktionaler Ausführungseinheiten (nicht dargestellt) auf, wie z. B. Ausführungseinheiten und Lade-Einspeicher-Einheiten. Verarbeitungsvorgänge, die für jede der funktionalen Ausführungseinheiten spezifisch sind, können in einer Pipeline ausgeführt werden, was es einem neuen Befehl ermöglicht, zur Ausführung ausgegeben zu werden, bevor ein vorheriger Befehl seine Ausführung abgeschlossen hat. Eine beliebige Kombination von funktionalen Ausführungseinheiten innerhalb eines gegebenen SM 310 kann bereitgestellt werden. In verschiedenen Ausführungsformen können die funktionalen Ausführungseinheiten ausgestaltet sein, um eine Vielzahl verschiedener Operationen zu unterstützen, einschließlich Ganzzahl- und Gleitkommaarithmetik (z. B. Addition und Multiplikation), Vergleichsoperationen, boolesche Operationen (AND, OR, XOR), Bitverschiebung und Berechnung verschiedener algebraischer Funktionen (z. B. planare Interpolation und trigonometrische, exponentielle und logarithmische Funktionen usw.). Vorteilhafterweise kann ein und dieselbe funktionale Ausführungseinheit ausgestaltet sein, um verschiedene Operationen durchzuführen.
  • Im Betrieb ist jede SM 310 ausgestaltet, um eine oder mehrere Thread-Gruppen zu verarbeiten. Wie hierin verwendet, bezieht sich eine „Thread-Gruppe“ oder „Warp“ auf eine Gruppe von Threads, die gleichzeitig das gleiche Programm auf unterschiedlichen Eingabedaten ausführen, wobei ein Thread der Gruppe einer anderen Ausführungseinheit innerhalb eines SM 310 zugewiesen ist. Eine Thread-Gruppe kann weniger Threads aufweisen als die Anzahl der Ausführungseinheiten innerhalb des SM 310; in diesem Fall können einige der Ausführungseinheiten während Zyklen im Leerlauf sein, wenn diese Thread-Gruppe verarbeitet wird. Eine Thread-Gruppe kann auch mehr Threads aufweisen als die Anzahl der Ausführungseinheiten innerhalb des SM 310, in diesem Fall kann die Verarbeitung in aufeinanderfolgenden Taktzyklen erfolgen. Da jeder SM 310 bis zu G Thread-Gruppen gleichzeitig unterstützen kann, folgt daraus, dass im GPC 208 zu jedem beliebigen Zeitpunkt bis zu G*M Thread-Gruppen ausgeführt werden können.
  • Zusätzlich können mehrere in Beziehung stehende Thread-Gruppen zur gleichen Zeit innerhalb eines SM 310 aktiv sein (in verschiedenen Phasen der Ausführung). Diese Sammlung von Thread-Gruppen wird hierin als „kooperatives Thread-Array“ („cooperative thread array“, „CTA“) oder „Thread-Array“ bezeichnet. Die Größe eines bestimmten CTA ist gleich m*k, wobei k die Anzahl von gleichzeitig ausgeführten Threads in einer Thread-Gruppe ist, die typischerweise ein ganzzahliges Vielfaches der Anzahl von Ausführungseinheiten innerhalb des SM 310 ist, und m die Anzahl von Thread-Gruppen ist, die gleichzeitig innerhalb des SM 310 aktiv sind. In verschiedenen Ausführungsformen beschreibt eine Softwareanwendung, die in der Programmiersprache „Compute Unified Device Architecture“ (CUDA) geschrieben ist, das Verhalten und den Betrieb von Threads, die auf dem GPC 208 ausgeführt werden, einschließlich aller oben beschriebenen Verhaltensweisen und Operationen. Eine gegebene Verarbeitungsaufgabe kann in einem CUDA-Programm so spezifiziert werden, dass der SM 310 ausgestaltet werden kann, um Mehrzweck-Rechenoperationen durchzuführen und/oder zu verwalten.
  • Obwohl es in 3 nicht dargestellt ist, enthält jeder SM 310 einen Level Eins (L1)-Cache oder verwendet Platz in einem entsprechenden L1-Cache außerhalb des SM 310, um unter anderem Lade- und Einspeicheroperationen zu unterstützen, die von den Ausführungseinheiten durchgeführt werden. Jeder SM 310 hat auch Zugriff auf Level Zwei (L2) Caches (nicht dargestellt), die von allen GPCs 208 in der PPU 202 gemeinsam genutzt werden. Die L2-Caches können verwendet werden, um Daten zwischen Threads zu übertragen. Schließlich haben die SMs 310 auch Zugriff auf den „globalen“ Speicher außerhalb des Chips, der den PP-Speicher 204 und/oder den Systemspeicher 104 aufweisen kann. Es ist klar, dass jeder Speicher außerhalb der PPU 202 als globaler Speicher verwendet werden kann. Zusätzlich kann, wie in 3 gezeigt, ein Level-Eins-Punkt-Fünf (L1.5) Cache 335 im GPC 208 vorhanden und ausgestaltet sein, um Daten zu empfangen und zu halten, die über die Speicherschnittstelle 214 von SM 310 vom Speicher angefordert werden. Solche Daten können ohne Einschränkung Befehle, einheitliche Daten und konstante Daten aufweisen. In Ausführungsformen mit mehreren SMs 310 innerhalb des GPC 208 können die SMs 310 vorteilhaft gemeinsame Befehle und Daten nutzen, die im L1.5-Cache 335 zwischengespeichert sind.
  • Jeder GPC 208 kann eine zugeordnete Speicherverwaltungseinheit (memory management unit, MMU) 320 aufweisen, die ausgestaltet ist, um virtuelle Adressen auf physikalische Adressen abzubilden. In verschiedenen Ausführungsformen kann die MMU 320 entweder im GPC 208 oder in der Speicherschnittstelle 214 untergebracht sein. Die MMU 320 weist einen Satz von Seitentabelleneinträgen (page table entries, PTEs) auf, die dazu verwendet werden, eine virtuelle Adresse auf eine physikalische Adresse einer Kachel oder Speicherseite abzubilden, sowie optional einen Cache-Zeilenindex. Die MMU 320 kann Adressübersetzungspuffer (address translation lookaside buffers, TLB) oder Caches aufweisen, die sich in SMs 310, in einem oder mehreren L1-Caches oder im GPC 208 befinden können.
  • In Grafik- und Rechenanwendungen kann der GPC 208 so ausgestaltet sein, dass jedes SM 310 mit einer Textureinheit 315 gekoppelt ist, um Texturabbildungsoperationen durchzuführen, wie z. B. Bestimmen von Texturmusterpositionen, Lesen von Texturdaten und Filtern von Texturdaten.
  • Im Betrieb überträgt jeder SM 310 eine bearbeitete Aufgabe an die Arbeitsverteilungs-Kreuzschiene 330, um die bearbeitete Aufgabe einem anderen GPC 208 zur weiteren Bearbeitung bereitzustellen oder um die bearbeitete Aufgabe in einem L2-Cache (nicht dargestellt), einem Parallelverarbeitungsspeicher 204 oder einem Systemspeicher 104 über die Kreuzschieneneinheit 210 zu speichern. Darüber hinaus ist eine Vor-Raster-Operationen(pre-raster operations, pre-ROP)-Einheit 325 ausgestaltet, um Daten vom SM 310 zu empfangen, Daten an eine oder mehrere Raster-Operationen(raster operations, ROP)-Einheiten innerhalb der Partitionseinheiten 215 zu leiten, Optimierungen für eine Farbmischung durchzuführen, Bildpunkt-Farb-Daten zu organisieren und Adressübersetzungen durchzuführen.
  • Es wird deutlich, dass die hier beschriebene Kernarchitektur veranschaulichend ist und dass Veränderungen und Modifikationen möglich sind. Unter anderem kann eine beliebige Anzahl von Verarbeitungseinheiten, wie SMs 310, Textureinheiten 315 oder pre-ROP-Einheiten 325, in der GPC 208 vorhanden sein. Wie oben in Verbindung mit 2 beschrieben, kann die PPU 202 ferner eine beliebige Anzahl von GPCs 208 aufweisen, die ausgestaltet sind, um einander funktional ähnlich zu sein, so dass das Ausführungsverhalten nicht davon abhängt, welcher GPC 208 eine bestimmte Verarbeitungsaufgabe erhält. Ferner arbeitet jeder GPC 208 unabhängig von den anderen GPCs 208 in der PPU 202, um Aufgaben für ein oder mehrere Anwendungsprogramme auszuführen. In Anbetracht des Vorhergehenden werden Fachleute verstehen, dass die in den 1-3 beschriebene Architektur den Umfang der verschiedenen Ausführungsformen der vorliegenden Offenbarung in keiner Weise einschränkt.
  • Es ist bitte zu beachten, dass Verweise auf gemeinsam genutzten Speicher, wie sie hier verwendet werden, einen oder mehrere technisch mögliche Speicher aufweisen können, einschließlich, ohne Einschränkung, eines lokalen Speichers, der von einem oder mehreren SMs 310 gemeinsam genutzt wird, oder eines über die Speicherschnittstelle 214 zugreifbaren Speichers, wie z. B. eines Cache-Speichers, eines Parallelverarbeitungsspeichers 204 oder eines Systemspeichers 104. Des Weiteren ist zu beachten, dass Verweise auf Cache-Speicher, wie sie hier verwendet werden, einen oder mehrere technisch mögliche Speicher aufweisen können, einschließlich, ohne Einschränkung, eines L1-Cache, eines L1.5-Cache und der L2-Caches.
  • Feingranularer lokaler Kontrollpunkt und Wiederherstellung
  • Wie hierin beschrieben, führt die PPU 202 einen feingranularen lokalen Kontrollpunkt und eine Wiederherstellung an Befehlsebenengrenzen von Speicher-Clients innerhalb der PPU 202 aus. Wie hierin weiter beschrieben, ist ein Speicher-Client eine beliebige Systemkomponente, die Speicher-Ladeoperationen und/oder Einspeicheroperationen in einem beliebigen Speicher durchführt. Speicher-Clients weisen ohne Einschränkung Streaming-Multiprozessoren (SMs), globale Konstant-Caches (GCCs), Kopiermaschinen 434, Kontextwechsler und/oder dergleichen auf. Ein Software-Wiederherstellungstreiber speichert periodisch lokale Kontrollpunkte für die Speicher-Clients in der PPU 202. Der Software-Wiederherstellungstreiber kann in dem Gerätetreiber 103, in einem separaten CUDA-Treiber und/oder dergleichen enthalten sein. Der Software-Wiederherstellungstreiber nutzt die Funktion Compute Instruction Level Preemption (CILP) der PPU 202, um die Ausführung an einer PPU 202-Programmbefehlsgrenze anzuhalten. Wenn die Speicher-Clients innerhalb der PPU 202 angehalten wurden, speichert der Software-Wiederherstellungstreiber einen Kontrollpunkt, der den Mikroarchitektur-Status der Speicher-Clients aufweist. Wenn ein Speicher-Client einen Speicherfehler entdeckt, verhindert der Speicher-Client, dass weitere Daten von dem Speicher-Client gespeichert oder an das Speichersystem übertragen werden, wodurch verhindert wird, dass sich der Speicherfehler auf andere Speicher-Clients, auf andere PPUs 202 oder auf die CPU 102 ausbreitet. Der Speicher-Client blockiert auch Kontextwechsel und Speicherbarrieren, um den Speicherfehler einzudämmen. Der Speicher-Client leitet eine oder mehrere Halteoperationen ein, um Befehle aus beliebigen Befehlswarteschlangen in dem Speicher-Client zu entnehmen, um alle anstehenden Speicheroperationen zu entfernen. Als Ergebnis bewahrt der Speicher-Client die Integrität des vorherigen lokalen Kontrollpunkts und ermöglicht so dem Software-Wiederherstellungstreiber einen zuverlässigen Neustart vom vorherigen lokalen Kontrollpunkt. Der Speicher-Client speichert Fehlerprotokolldaten, die Daten aufweisen, die dem Speicherfehler zugeordnet sind, benachrichtigt den Software-Wiederherstellungstreiber und hält an. Der Software-Wiederherstellungstreiber greift dann auf die Fehlerprotokolldaten zu, um die Art des Speicherfehlers zu ermitteln, stellt den vorherigen lokalen Kontrollpunkt wieder her und startet den blockierten Speicher-Client neu.
  • 4 ist ein Blockdiagramm des Speicherzugriffssystems 400, das in der PPU 202 und dem GPC 208 von 2 gemäß verschiedener Ausführungsformen enthalten ist. Wie gezeigt, weist das Speicherzugriffssystem 400 ohne Einschränkung die MMU 320, eine Speichersteuerungslogik 405, einen Speicher 420 und Speicher-Clients 430 auf. Die Speichersteuerungslogik 405 weist, ohne Einschränkung, eine ECC-Schaltung 410 auf. Die ECC-Schaltung 410 ist stellvertretend für eine oder mehrere ECC-Schaltungen und/oder eine ECC-Schutzlogik, die in die MMU 320 und/oder einen beliebigen Speicher 420, einschließlich DRAM 220, L2-Cache, anderen Speicher 424 und/oder dergleichen, eingebettet sind oder diese unterstützen. Der Speicher 420 weist ohne Einschränkung DRAM 220, einen Level-2-Cache (L2-Cache) 422 und anderen Speicher 424 auf. Die Speicher-Clients 430 weisen ohne Einschränkung einen SM 310, einen globalen Konstant-Cache (GCC) 432, eine Kopiermaschine 434 und einen Kontextwechsler 436 auf.
  • In einigen Ausführungsformen kann das Speicherzugriffssystem 400 mehrere Instanzen der Speichersteuerungslogik 405 aufweisen, wobei jede Instanz der Speichersteuerungslogik 405 eine separate ECC-Schaltung 410 aufweisen kann. In solchen Ausführungsformen kann eine Instanz der Speichersteuerungslogik 405 den DRAM 220 steuern. Mehrere Instanzen der Speichersteuerungslogik 405 können die verschiedenen Cache-Speicher in der Cache-Hierarchie steuern, wobei eine erste Instanz den L2-Cache 422 steuern kann, eine zweite Instanz einen L1.5-Cache steuern kann, eine dritte Instanz einen L1-Cache steuern kann und so weiter. Ebenso können mehrere Instanzen der Speichersteuerungslogik 405 den anderen Speicher 424 steuern, wobei jede erste Instanz einen unterschiedlichen Speicher steuern kann, der in dem anderen Speicher 424 enthalten ist.
  • Wie hierin beschrieben, befindet sich der DRAM 220 im PP-Speicher 204. Zusätzlich zu Datenbits weist der DRAM 220 Fehlerkorrekturcode-Bits (ECC) auf. Wenn ein Speicher-Client 430 Daten aus dem DRAM 220 lädt, verarbeitet die dem DRAM 220 zugeordnete ECC-Schaltung 410 die Datenbits und ECC-Bits, um Speicherfehler zu erkennen und/oder zu korrigieren. Bei einer typischen ECC-Implementierung ist die ECC-Schaltung 410 in der Lage, Ein-Bit-Fehler zu korrigieren und Zwei-Bit-Fehler zu erkennen. Weiter entwickelte ECC-Schaltungen 410 sind in der Lage, Zwei- oder Mehr-Bit-Fehler zu korrigieren und/oder Drei- oder Mehr-Bit-Fehler zu erkennen. Im Allgemeinen kann die ECC-Schaltung 410, wenn sie einen korrigierbaren ECC-Fehler erkennt, den ECC-Fehler korrigieren, ohne andere Systemkomponenten über den ECC-Fehler zu informieren. Wenn daher ein Speicher-Client 430 Daten aus dem DRAM 220 lädt, die ECC-Schaltung 410 feststellt, dass die Daten fehlerfrei sind oder einen korrigierbaren Fehler aufweisen, dann gibt der DRAM 220 die Daten zusammen mit einem Hinweissignal, das die Daten als nicht beschädigt kennzeichnet, an den anfordernden Speicher-Client 430 zurück. In einigen Ausführungsformen kann das Signal in Form einer Drahtverbindung vorliegen, die einen ersten Spannungspegel aufweist, wenn die Daten nicht beschädigt sind (was gültige Daten anzeigt), oder einen zweiten Spannungspegel, wenn die Daten beschädigt sind (was verfälschte Daten anzeigt). Wenn jedoch die ECC-Schaltung 410 feststellt, dass die Daten einen nicht korrigierbaren ECC-Fehler aufweisen, gibt der DRAM 220 die Daten zusammen mit einem Hinweissignal an den anfordernden Speicher-Client 430 zurück, das die Daten als fehlerhaft identifiziert, indem es ein „Giftmuster“ zurückgibt, das einen Haltezustand signalisiert. Zusätzlich führt eine eingehende Speicher-Einspeicheroperation zu einem Speichern des Giftmusters im DRAM 220. Die Datenbits, die die Daten und/oder das Giftmuster darstellen, werden hier als „Speicherwort“ bezeichnet. Zum Beispiel führt eine Auslagerung einer Cache-Zeile aus dem L2-Cache 422, die einen ECC-Fehler und/oder ein Giftmuster aufweist, zu einem Speichern des Giftmusters im DRAM 220, um anzuzeigen, dass die ausgelagerte Cache-Zeile beschädigt ist. Wenn ein anderer Speicher-Client 430 nachfolgend dieselben Daten aus dem Speicher lädt, dann erkennt die ECC 410-Schaltung, dass die Daten mit dem Giftmuster gespeichert wurden. Als Ergebnis gibt der DRAM 220 die Daten an den anfragenden Speicher-Client 430 zusammen mit einem Hinweissignal zurück, das die Daten als beschädigt kennzeichnet, was einen Haltezustand signalisiert. Ferner, wenn auf Daten aus dem DRAM 220 zugegriffen wird, werden die Daten auch in dem L2-Cache 422 gespeichert, einschließlich der Datengiftbits. Auf diese Weise empfängt ein Speicher-Client 430, der auf dieselben Daten zugreift, ein Hinweissignal, das die Daten als beschädigt kennzeichnet, ob die Daten nun aus dem DRAM 220 oder dem L2-Cache 422 empfangen wurden.
  • Speicher-Clients 430 haben auch Zugriff auf den L2-Cache 422, wobei der L2-Cache 422 verwendet werden kann, um Daten zwischen Threads zu übertragen. Zusätzlich zu Datenbits weist der L2-Cache 422 ECC-Bits und Datengiftbits auf. In einigen Ausführungsformen können die Datengiftbits eine Erweiterung der Cache-Kennzeichnungsbits sein. Wenn ein Speicher-Client 430 Daten aus dem L2-Cache 422 lädt, verarbeitet die dem L2-Cache 422 zugeordnete ECC-Schaltung 410 die Datenbits und ECC-Bits, um Speicherfehler zu erkennen und/oder zu korrigieren. In einer typischen ECC-Implementierung ist die ECC-Schaltung 410 in der Lage, Ein-Bit-Fehler zu korrigieren und Zwei-Bit-Fehler zu erkennen. Weiter entwickelte ECC-Schaltungen 410 sind in der Lage, Zwei- oder Mehr-Bit-Fehler zu korrigieren und/oder Drei- oder Mehr-Bit-Fehler zu erkennen. Wenn ein Speicher-Client 430 Daten aus dem L2-Cache 422 lädt und die ECC-Schaltung 410 feststellt, dass die Daten keine Fehler aufweisen oder einen korrigierbaren ECC-Fehler aufweisen, gibt der L2-Cache 422 die Daten zusammen mit einem Hinweissignal, das die Daten als nicht beschädigt kennzeichnet, an den anfordernden Speicher-Client 430 zurück. Stellt die ECC-Schaltung 410 jedoch fest, dass die Daten einen nicht korrigierbaren ECC-Fehler aufweisen, gibt der L2-Cache 422 die Daten an den anfordernden Speicher-Client 430 zusammen mit einem Hinweissignal zurück, das die Daten als beschädigt identifiziert, indem ein „Giftmuster“ zurückgegeben wird, was einen Haltezustand signalisiert. Zusätzlich führt eine eingehende Speicher-Einspeicheroperation zu einem Speichern des Giftmusters im DRAM 220. Zum Beispiel führt eine Auslagerung einer Cache-Zeile aus dem L2-Cache 422, die einen ECC-Fehler und/oder ein Giftmuster aufweist, zu einem Speichern des Giftmusters in dem DRAM, um anzuzeigen, dass die ausgelagerte Cache-Zeile beschädigt ist. Wenn ein anderer Speicher-Client 430 nachfolgend dieselben Daten aus dem Speicher lädt, stellt die ECC-Schaltung 410 fest, dass die Daten mit dem Giftmuster gespeichert wurden. Als Ergebnis gibt der DRAM 220 die Daten an den anfragenden Speicher-Client 430 zusammen mit einem Hinweissignal zurück, das die Daten als beschädigt kennzeichnet, was einen Haltezustand signalisiert. Ferner, wenn Daten aus dem L2-Cache 422 entfernt und an den DRAM 220 übertragen werden, werden die Daten in dem DRAM 220 zusammen mit den Datengiftbits gespeichert. Auf diese Weise empfängt ein Speicher-Client 430, der auf dieselben Daten zugreift, ein Hinweissignal, das die Daten als beschädigt identifiziert, ob die Daten nun aus dem DRAM 220 oder dem L2-Cache 422 empfangen werden.
  • Ferner wird, wenn Daten aus einer Cache-Zeile im L2-Cache 422 in dem DRAM 220 gespeichert werden, ein Datengiftbit gesetzt, wenn entweder die Cache-Zeile ein gesetztes Giftbit aufweist und/oder wenn die Cache-Zeile einen ECC-Fehler aufweist. In jedem Fall verwendet der DRAM 220 kein separates Datengiftbit. Stattdessen speichert der DRAM 220 die Daten unter Verwendung eines Giftmusters, das anzeigt, dass die gespeicherten Daten beschädigt sind. Das in dem DRAM 220 gespeicherte Giftmuster behält die ECC-Eigenschaften ohne zusätzlichen Speicheraufwand zum Unterstützen des Gifthinweises. Daher führt jede nachfolgende Speicheroperation, die in dem Bereich im DRAM 220 stattfindet, in dem die Cache-Zeile gespeichert war, zu einem erkannten Fehler. Dieser Zustand resultiert daraus, dass die Speichersteuerungslogik 405 Daten in dem DRAM 220 unter Verwendung des Giftmusters speichert. Zum Beispiel können Daten aus dem L2-Cache 422 als beschädigt markiert werden, wenn sie in dem DRAM 220 gespeichert sind, und dieselben Daten verursachen einen weiteren ECC-Fehler in dem DRAM 220. Bei den offenbarten Techniken behalten die Daten im DRAM 220 weiterhin die Datengiftbits bei. Daher werden, unabhängig davon, ob die im DRAM 220 gespeicherten Daten aus dem L2-Cache 422 beschädigt sind oder nicht, nachfolgende Fehler in dem DRAM 220 erkannt. Als Ergebnis werden Speicherfehler, die in dem L2-Cache 422 auftreten, in dem DRAM 220 beibehalten, ebenso wie nachfolgende Fehler, die in dem DRAM 220 auftreten. Im Allgemeinen ist das Giftmuster eine eindeutige Kombination aus Einsen und Nullen, die die entsprechenden Daten als Gift kennzeichnet. Ein ECC-Fehler im Giftmuster wird als ein nicht korrigierbarer Fehler behandelt. Im Gegensatz zur Fehlerkorrektur für reguläre Daten wird ein einzelner Bitfehler im Giftmuster nicht korrigiert. Daher hat das Giftmuster den gleichen Beschädigungsschutz wie die entsprechenden Daten. Vorteilhafterweise weist das Giftmuster die gleiche Eigenschaft der Doppelbit-Fehlererkennung auf wie reguläre Daten.
  • Der andere Speicher 424 weist einen beliebigen anderen technisch realisierbaren Speicher auf, zum Beispiel kann er einen oder mehrere technisch realisierbare Speicher aufweisen, einschließlich, aber nicht beschränkt auf statische Direktzugriffsspeicher (static random access memories, SRAMs), einen L1-Cache, einen L1.5-Cache und/oder dergleichen. Diese anderen Speicher 424 funktionieren im Wesentlichen genauso wie der DRAM 220 und der L2-Cache 422, wie hier beschrieben. Daher können die hier offenbarten Techniken auf einen beliebigen oder mehrere der in dem anderen Speicher 424 vorhandenen Speicher angewendet werden.
  • In einigen Ausführungsformen gibt die MMU 320 kein Giftmuster zurück, da die Speicherdaten in der MMU 320 Nur-Lese-Daten sind. Stattdessen, wenn die MMU 320 einen Fehler feststellt, erklärt die MMU 320 die betroffenen Daten innerhalb der MMU 320 für ungültig und holt neue Daten aus dem DRAM 220. Wenn der DRAM 220 jedoch Daten mit einem Giftmuster an die MMU 320 zurückgibt, sendet die MMU 320 eine MMU Negativbestätigung (MMU_NACK) an den anfordernden Speicher-Client 430, um dem anfordernden Speicher-Client 430 zu signalisieren, dass die Daten innerhalb der MMU 320 beschädigt sind.
  • Wenn ein Speicherfehler auftritt, wird der anfordernde Speicher-Client 430 angehalten, aber die MMU 320, der Speicher 420 und andere gemeinsam genutzte Ressourcen werden nicht angehalten. Da die MMU 320 und der Speicher 420 gemeinsam genutzte Ressourcen sind, fahren die MMU 320 und der Speicher 420 stattdessen fort, Speicher-Lade- und -Einspeicheroperationen von anderen Speicher-Clients 430 zu bedienen. Auf diese Weise fahren die Speicher-Clients 430, die nicht angehalten haben, fort, Lade- und Einspeicheroperationen für den Speicher 420 auszuführen, solange die Speicher-Clients 430 nicht versuchen, eine Ladeoperation durchzuführen, die zu einem Speicherfehler führt. Als Ergebnis sind die einzigen Speicher-Clients 430, die anhalten, diejenigen Speicher-Clients 430, die auf einen Speicherfehler stoßen. Auf diese Weise hat ein Fehler, der von einem Speicher-Client 430 erkannt wird, keine Auswirkungen auf die Ausführung anderer Speicher-Clients 430.
  • Wie hierin beschrieben, weist der SM 310 eine Reihe von funktionalen Ausführungseinheiten auf, wie z. B. Ausführungseinheiten und Lade-Einspeicher-Einheiten. Im Betrieb lädt der SM 310 Daten aus einem oder mehreren von dem DRAM 220, dem L2-Cache 422 und einem anderen Speichern 424. Während einer Speicher-Ladeoperation aus dem DRAM 220, dem L2-Cache 422 oder einem anderen Speicher 424 empfängt die SM 310 die Daten zusammen mit einem Hinweissignal, das angibt, ob die Daten beschädigt sind. Wenn das Signal angibt, dass die Daten nicht beschädigt sind, dann schließt der SM 310 die Speicher-Ladeoperation ab und setzt die Ausführung fort. Wenn jedoch das Hinweissignal die Daten als beschädigt identifiziert, dann deaktiviert das SM 310 Speicherungen im Speicher, Speicherungen in Dateisystemen und andere Datenübertragungen vom SM 310, um zu verhindern, dass die beschädigten Daten andere Plätze im Speicher 420, in Speicher-Clients 430 und/oder anderen Komponenten der PPU 202 beeinträchtigen.
  • Der SM 310 leitet eine oder mehrere Halteoperationen ein, um weitere Speicher-Ladeoperationen und/oder Speicher-Einspeicheroperationen zu deaktivieren, einschließlich Speicherbarrieren und Kontextwechsel. Zu dem Zeitpunkt, zu dem der SM 310 die Haltesequenz einleitet, können mehrere Speicher-Lade- und/oder Speicher-Einspeicheroperationen in der Pipeline des SM 310 anhängig sein. Wenn die Speicher-Lade- und/oder - Einspeicheroperationen in der Pipeline verbleiben, dann werden die Speicher-Lade- und/oder -Einspeicheroperationen nicht ordnungsgemäß ausgeführt, bevor die SM 310 die Ausführung an einem früheren Kontrollpunkt wieder aufnimmt. Um zu verhindern, dass die Speicher-Lade- und/oder - Einspeicheroperationen ausgeführt werden, entleert und verwirft die SM 310 alle anhängigen Speicher-Lade- und/oder -Einspeicheroperationen in der Pipeline.
  • Als Teil der Haltesequenz erzeugt und speichert der SM 310 Fehlerprotokolldaten, die angeben, dass der SM 310 aufgrund eines Speicherfehlers angehalten wurde, den Ort des Speicherfehlers, den Befehl, der zum Zeitpunkt des Speicherfehlers ausgeführt wurde, den Kontext und/oder Prozess, der zum Zeitpunkt des Speicherfehlers auf dem SM 310 ausgeführt wurde, den SM 310, der den Speicherfehler erkannt hat, und/oder Ähnliches. In einigen Ausführungsformen kann der Speicherfehler dem Kontext zugeordnet werden. Zum Beispiel können bestimmte Speicherfehler, wie z. B. interne Fehler in einem SM 310, der Befehlsgrenze zuordenbar sein. Andere Speicherfehler, wie z. B. Gifthinweise, die vom L2-Cache 422 und/oder DRAM 220 an den SM 310 zurückgegeben werden, können nicht einer Befehlsgrenze zuordenbar sein. Der Software-Wiederherstellungstreiber setzt das System zurück und wertet die Fehlerprotokolldaten aus. Der Software-Wiederherstellungstreiber stellt den letzten lokalen Kontrollpunkt für den SM 310 wieder her. Abhängig von dem Prozess und/oder Kontext, der zum Zeitpunkt des Speicherfehlers ausgeführt wird, kann der Software-Wiederherstellungstreiber auch einen oder mehrere andere Speicher-Clients 430 auf den letzten lokalen Kontrollpunkt zurücksetzen. Der Software-Wiederherstellungstreiber veranlasst den SM 310 und andere betroffene Speicher-Clients 430, den Betrieb beginnend mit dem wiederhergestellten Kontrollpunkt wieder aufzunehmen.
  • In einigen Ausführungsformen kann der SM 310 einen internen Speicher aufweisen, wie zum Beispiel Registerdateien, einen L1-Cache und/oder dergleichen. Dieser interne Speicher kann auch ECC-Bits und Datengiftbits aufweisen. Wenn der SM 310 auf den internen Speicher zugreift, kann der SM 310 feststellen, dass die Daten in dem internen Speicher beschädigt sind. Wenn der SM 310 feststellt, dass die Daten in dem internen Speicher beschädigt sind, kann der SM 310 die gleichen Techniken ausführen, die hier in Verbindung mit dem DRAM 220, dem L2-Cache 422 und anderen Speichern 424 beschrieben sind.
  • Im Betrieb ruft der globale Konstant-Cache (GCC) 432, der hier auch als konstanter Cache-Speicher bezeichnet wird, Daten ab, lädt Daten aus einem oder mehreren von dem DRAM 220, dem L2-Cache 422 und einem anderen Speicher 424 und speichert die Daten in dem GCC 432. Der GCC 432 speichert Daten wie beispielsweise konstante Werte, ausführbare Befehle und beliebige andere Daten, die von dem SM 310 und optional von anderen Speicher-Clients 430 gelesen, aber nicht geschrieben werden können. Auf diese Weise stellt der GCC 432 für die anderen Speicher-Clients 430 einen Nur-Lese-Speicher dar. Im Betrieb lädt der GCC 432 Daten aus einem oder mehreren der folgenden: dem DRAM 220, dem L2-Cache 422 und anderen Speichern 424. Während einer Speicher-Ladeoperation aus dem DRAM 220, dem L2-Cache 422 oder einem anderen Speicher 424 empfängt der GCC 432 die Daten zusammen mit einem Hinweissignal, das angibt, ob die Daten beschädigt sind. Wenn das Hinweissignal die Daten als nicht beschädigt anzeigt, dann beendet der GCC 432 die Speicher-Ladeoperation und setzt die Ausführung fort. Wenn jedoch das Hinweissignal die Daten als beschädigt anzeigt, dann deaktiviert der GCC 432 Speicherungen im Speicher, Speicherungen in Dateisystemen und andere Datenübertragungen von dem GCC 432, um zu verhindern, dass die beschädigten Daten andere Plätze des Speichers 420, Speicher-Clients 430 und/oder andere Komponenten der PPU 202 beeinträchtigen.
  • Der GCC 432 leitet eine oder mehrere Halteoperationen ein, um weitere Speicher-Ladeoperationen und/oder Speicher-Einspeicheroperationen zu deaktivieren, einschließlich Speicherbarrieren und Kontextwechsel. Als Teil der Haltesequenz erzeugt und speichert der GCC 432 Fehlerprotokolldaten, die anzeigen, dass der GCC 432 aufgrund eines Speicherfehlers angehalten wurde, den Ort des Speicherfehlers, den Befehl, der zum Zeitpunkt des Speicherfehlers ausgeführt wurde, den Kontext und/oder den Prozess, der zum Zeitpunkt des Speicherfehlers auf dem SM 310 ausgeführt wurde, den GCC 432, der den Speicherfehler erkannt hat, und/oder Ähnliches. Der Software-Wiederherstellungstreiber setzt das System zurück und analysiert die Fehlerprotokolldaten. Der Software-Wiederherstellungstreiber stellt den letzten lokalen Kontrollpunkt für den GCC 432 wieder her. Abhängig von dem Prozess und/oder Kontext, der zum Zeitpunkt des Speicherfehlers ausgeführt wurde, kann der Software-Wiederherstellungstreiber auch einen oder mehrere andere Speicher-Clients 430 auf den letzten lokalen Kontrollpunkt zurücksetzen. Der Software-Wiederherstellungstreiber veranlasst den GCC 432 und andere betroffene Speicher-Clients 430, den Betrieb beginnend mit dem wiederhergestellten Kontrollpunkt wieder aufzunehmen.
  • In einigen Ausführungsformen kann der GCC 432 einen internen Speicher aufweisen, wie z. B. Registerdateien, einen L1-Cache und/oder Ähnliches. Dieser interne Speicher kann auch ECC-Bits und Datengiftbits aufweisen. Wenn der GCC 432 auf den internen Speicher zugreift, kann der GCC 432 als Ergebnis feststellen, dass Daten in dem internen Speicher beschädigt sind. Wenn der GCC 432 feststellt, dass Daten in dem internen Speicher beschädigt sind, kann der GCC 432 die gleichen Techniken durchführen, wie sie hier in Verbindung mit dem DRAM 220, dem L2-Cache 422 und anderen Speichern 424 beschrieben sind.
  • Im Betrieb führt die Kopiermaschine 434 Blockkopieroperationen von Daten in Form von Direktspeicherzugriffs(direct memory access, DMA)-Operationen aus. Die Kopiermaschine 434 lädt Daten von einer Quellposition in dem Speicher 420 und speichert die Daten an einer entsprechenden Zielposition in dem Speicher 420. Während einer Speicher-Ladeoperation aus dem Speicher 420 empfängt die Kopiermaschine 434 die Daten zusammen mit einem Hinweissignal, das angibt, ob die Daten beschädigt sind. Wenn das Hinweissignal angibt, dass die Daten nicht beschädigt sind, dann schließt die Kopiermaschine 434 die Speicher-Ladeoperation ab und setzt die BlockKopieroperation fort. Wenn jedoch das Hinweissignal die Daten als beschädigt anzeigt, dann deaktiviert die Kopiermaschine 434 Speicherungen in den Speicher, Speicherungen in Dateisysteme und andere Datenübertragungen von der Kopiermaschine 434, um zu verhindern, dass die beschädigten Daten andere Plätze des Speichers 420, Speicher-Clients 430 und/oder andere Komponenten der PPU 202 beeinträchtigen.
  • Die Kopiermaschine 434 leitet einen oder mehrere Haltevorgänge ein, um die Blockkopieroperation zu stoppen und weitere Speicher-Ladeoperationen und/oder Speicher-Einspeicheroperationen zu deaktivieren. Als Teil der Haltesequenz erzeugt und speichert die Kopiermaschine 434 Fehlerprotokolldaten, die angeben, dass die Kopiermaschine 434 aufgrund eines Speicherfehlers angehalten wurde, den Ort des Speicherfehlers, den Befehl, der zum Zeitpunkt des Speicherfehlers ausgeführt wurde, den Kontext und/oder den Prozess, der zum Zeitpunkt des Speicherfehlers auf der Kopiermaschine 434 ausgeführt wurde, die Kopiermaschine 434, die den Speicherfehler erkannt hat, und/oder dergleichen. Der Software-Wiederherstellungstreiber setzt die Maschine zurück und analysiert die Fehlerprotokolldaten. Der Software-Wiederherstellungstreiber stellt den letzten lokalen Kontrollpunkt der Kopiermaschine 434 wieder her. Abhängig von dem Prozess und/oder Kontext, der zu der Zeit des Speicherfehlers ausgeführt wurde, kann der Software-Wiederherstellungstreiber auch einen oder mehrere andere Speicher-Clients 430 auf den letzten lokalen Kontrollpunkt zurücksetzen. Der Software-Wiederherstellungstreiber veranlasst die Kopiermaschine 434 und andere betroffene Speicher-Clients 430, den Betrieb beginnend mit dem wiederhergestellten Kontrollpunkt wieder aufzunehmen.
  • Im Betrieb unterstützt der Kontextwechsler 436 das Zeitscheibenverfahren für verschiedene Kontexte, wobei jeder Kontext ein Prozess oder Unterprozess ist. In einem Zeitscheiben-System führt der SM 310 einen Kontext für eine bestimmte Zeitdauer aus. Nach Ablauf der Zeitdauer hält der Kontextwechsler 436 den SM 310 an und speichert den aktuellen Kontext des SM 310 im Speicher 420. Der Kontextwechsler 436 stellt dem SM 310 einen neuen Kontext aus dem Speicher 420 wieder zur Verfügung und beginnt mit der Ausführung des neuen Kontexts. Auf diese Weise führt der SM 310 nacheinander Zeitscheiben von mehreren Kontexten aus. Wenn der Kontextwechsler 436 den neuen Kontext wiederherstellt, können die aus dem Speicher 420 geladenen Daten beschädigt sein.
  • Während der Wiederherstellung führt der Kontextwechsler 436 Speicher-Ladeoperationen aus dem Speicher 420 durch. Der Kontextwechsler 436 empfängt die Daten zusammen mit einem Hinweissignal, das angibt, ob die Daten beschädigt sind. Wenn das Hinweissignal anzeigt, dass die Daten nicht beschädigt sind, schließt der Kontextwechsler 436 die Speicher-Ladeoperation ab und setzt die Wiederherstellung fort. Wenn jedoch das Hinweissignal die Daten als beschädigt anzeigt, stoppt der Kontextwechsler 436 die Wiederherstellung und deaktiviert Speicherungen im Speicher, Speicherungen in Dateisystemen und andere Datenübertragungen von dem Kontextwechsler 436, um zu verhindern, dass die beschädigten Daten den entsprechenden SM 310, andere Plätze des Speichers 420, Speicher-Clients 430 und/oder andere Komponenten der PPU 202 beeinträchtigen. Der Kontextwechsler 436 hält den entsprechenden SM 310 in einem Haltezustand. Auf diese Weise verhindert der Kontextwechsler 436, dass der SM 310 einen beschädigten Kontext ausführt.
  • Der Kontextwechsler 436 leitet eine oder mehrere Halteoperationen ein, um die Wiederherstellung zu stoppen und weitere Speicher-Ladeoperationen und/oder Speicher-Einspeicheroperationen zu deaktivieren. Als Teil der Haltesequenz erzeugt und speichert der Kontextwechsler 436 Fehlerprotokolldaten, die anzeigen, dass der Kontextwechsler 436 aufgrund eines Speicherfehlers angehalten hat, den Ort des Speicherfehlers, den Befehl, der zum Zeitpunkt des Speicherfehlers ausgeführt wurde, den Kontext und/oder Prozess, der zu dem Zeitpunkt des Speicherfehlers auf dem Kontextwechsler 436 ausgeführt wurde, den Kontextwechsler 436, der den Speicherfehler erkannt hat, und/oder Ähnliches. Der Software-Wiederherstellungstreiber setzt das System zurück und wertet die Fehlerprotokolldaten aus. Der Software-Wiederherstellungstreiber stellt den letzten lokalen Kontrollpunkt im Kontextwechsler 436 wieder her. Abhängig von dem Prozess und/oder Kontext, der zum Zeitpunkt des Speicherfehlers ausgeführt wurde, kann der Software-Wiederherstellungstreiber auch einen oder mehrere andere Speicher-Clients 430 auf den letzten lokalen Kontrollpunkt zurücksetzen. Der Software-Wiederherstellungstreiber veranlasst den Kontextwechsler 436 und andere betroffene Speicher-Clients 430, den Betrieb beginnend mit dem wiederhergestellten Kontrollpunkt wieder aufzunehmen.
  • Der Prozess zum Verfolgen von Speicherfehlern variiert basierend darauf, ob der Speicherfehler in dem DRAM 220 oder dem L2-Cache 422 entstanden ist. In einem ersten Beispiel entsteht ein Speicherfehler in dem DRAM 220. Wenn ein Speicher-Client 430 auf Daten in dem DRAM 220 zugreift, die einen Speicherfehler aufweisen, erkennt die ECC-Schaltung 410 den Speicherfehler über die ECC-Bits. Eine Speichersteuerung, z. B. die Speichersteuerungslogik 405, speichert die Daten und die Datengiftbits aus dem DRAM 220 in einer verfügbaren Cache-Zeile in dem L2-Cache 422. Wenn ein zweiter Speicher-Client 430 nachfolgend auf dieselben Daten zugreift, dann lädt der zweite Speicher-Client 430 die Daten aus der Cache-Zeile im L2-Cache 422. Da die Cache-Zeile das Giftmuster aufweist, erhält der zweite Speicher-Client 430 einen Hinweis auf den Speicherfehler, obwohl der Speicherfehler seinen Ursprung in dem DRAM 220 hat.
  • In einem zweiten Beispiel entsteht ein Speicherfehler im L2-Cache 422. Wenn ein Speicher-Client 430 auf Daten in einer Cache-Zeile des L2-Cache 422 zugreift, die einen Speicherfehler aufweist, erkennt die ECC-Schaltung 410 den Speicherfehler über die ECC-Bits und speichert die Datengiftbits mit dem Giftmuster. Wenn nachfolgend die Cache-Zeile mit dem Speicherfehler aus dem L2-Cache 422 entfernt wird, speichert eine Speichersteuerung, wie z. B. die Speichersteuerungslogik 405, die Daten und die Datengiftbits aus der Cache-Zeile im L2-Cache 422 an der geeigneten Stelle in dem DRAM 220. Wenn ein Speicher-Client 430 später auf die Daten aus dem DRAM 220 zugreift, dann lädt der Speicher-Client 430 die Daten aus dem DRAM 220. Da der Speicher in dem DRAM das Giftmuster aufweist, erhält der Speicher-Client 430 einen Hinweis auf den Speicherfehler, auch wenn der Speicherfehler in dem L2-Cache 422 entstanden ist.
  • Bei Speicherzugriffen, wie z. B. Speicher-Lade- und Einspeicheroperationen, besteht die Aufgabe der MMU 320 darin, den Speicherzugriff eines Speicher-Clients 430 zu validieren und eine von dem Speicher-Client gesendete virtuelle Adresse in eine physische Adresse umzuwandeln, die für ein Zugreifen auf einen Speicherplatz innerhalb des L2-Cache 422 oder des DRAM 220 verwendet wird. Hauptsächlich prüft die MMU 320, um zu bestimmen, ob der Speicherzugriff legal ist. Wenn der Speicherzugriff illegal ist, gibt die MMU 320 eine negative MMU-Bestätigung (MMU_NACK) an den anfordernden Speicher-Client 430 zurück, um den Speicherzugriff als einen illegalen Zugriff zu kennzeichnen. In einigen Ausführungsformen kann die MMU 320 selbst als Speicher-Client 430 betrachtet werden, da in der MMU 320 gespeicherte Seitentabellen und/oder Ähnliches über Zusatzspeicherkopien verfügen, die im L2-Cache 422 und/oder DRAM 220 gespeichert sind. Die MMU 320 weist eine oder mehrere SRAM-Strukturen auf, die diese Seitentabellen und/oder Ähnliches speichern. Wenn die TLB in der MMU 320 keine Übersetzung für eine Speicherzugriffsanforderung hat, „geht“ die MMU 320 durch den Speicher des L2-Cache 422 und/oder DRAM 220, um Seitentabellen zu holen, um die vom Speicher-Client gesendete virtuelle Adresse in eine physikalische Adresse zu übersetzen.
  • Im Allgemeinen kann die MMU 320 auf zwei Arten von Fehlern stoßen. Bei einer ersten Fehlerart weist ein TLB-Eintrag in der MMU 320 einen Paritätsfehler oder einen ECC-Fehler auf. Bei dieser ersten Art von Fehler verwirft die MMU 320 den TLB-Eintrag und führt einen Seitendurchgang (page walk) durch, um die relevanten Seitentabellen aus dem L2-Cache 422 und/oder DRAM 220 neu zu laden. Die MMU 320 erholt sich von diesem Fehlertyp, ohne den Speicher-Client 430 benachrichtigen zu müssen, da davon ausgegangen wird, dass die TLB Nur-Lese-Daten aufweist. Bei einer zweiten Art von Fehler, wenn eine Seitenübersetzung, die als Teil eines Seitendurchgangs durchgeführt wird, von dem L2-Cache 422 und/oder DRAM 220 zurückgegeben wird, können die der Seitenübersetzung zugeordneten Daten vergiftet sein. Bei dieser Art von Fehler gibt die MMU 320 eine negative MMU-Bestätigung (MMU_NACK) an den anfordernden Speicher-Client 430 zurück, da die Quelle der Nur-Lese-Daten selbst korrekt ist. Da bei dieser Art von Fehler der TLB-Eintrag in der MMU 320 kein Vergiftungsmuster aufweist, wird keine vergiftete Übersetzung in der TLB gespeichert.
  • Es ist klar, dass das hier gezeigte System veranschaulichend ist und dass Änderungen und Modifikationen möglich sind. Die MMU 320 ist als eine einzelne Speicherverwaltungseinheit mit einer einzelnen ECC-Schaltung 410 dargestellt. Die offenbarten Techniken können jedoch mit einer beliebigen Anzahl und/oder beliebigen Instanzen von MMUs 320, Speichersteuerungslogik 405 und ECC-Schaltungen 410 in einer beliebigen technisch machbaren Kombination eingesetzt werden. Der Speicher 420 ist mit einem einzelnen DRAM 220 und einem einzelnen L2-Cache 422 dargestellt. Die offenbarten Techniken können jedoch mit einer beliebigen Anzahl von DRAMs 220, L2-Caches 422 und anderen Speichern 424 in jeder technisch machbaren Kombination eingesetzt werden. Ebenso sind die Speicher-Clients 430 als ein einzelner SM 310, ein einzelner GCC 432, eine einzelne Kopiermaschine 434 und ein einzelner Kontextwechsler 436 dargestellt. Die offenbarten Techniken können jedoch mittels einer beliebigen Anzahl von SMs 310, GCCs 432, Kopiermaschinen und Kontextwechslern 436 in jeder technisch machbaren Kombination eingesetzt werden.
  • In einigen Ausführungsformen können die offenbarten Techniken in einem System mit mehreren PPUs 202 eingesetzt werden, wobei beschädigte Daten auf einer ersten PPU 202 von einer zweiten PPU 202 geladen werden. Darüber hinaus können die offenbarten Techniken in einem System mit mehreren PPUs 202 verwendet werden, die über ein Netzwerk miteinander kommunizieren, sofern das Netzwerk ausgestaltet ist, um die Datengiftbits und/oder den Hinweis für beschädigte Daten über das Netzwerk zu übertragen. Darüber hinaus können die offenbarten Techniken in einem System mit einer partitionierten PPU 202 eingesetzt werden, bei dem eine einzelne PPU 202 von zwei oder mehr Mandanten gemeinsam genutzt wird, wobei eine korrekte Kontextzuweisung und Fehlerisolierung zwischen den Mandanten bereitgestellt wird.
  • In einem Beispiel greift ein SM 310, der auf einer ersten PPU 202 ausgeführt wird, auf Daten aus dem Speicher 420 auf einer zweiten PPU 202 zu. Während der auf der zweiten PPU 202 durchgeführten Speicher-Ladeoperation stellt die zweite PPU 202 einen Speicherfehler fest. Die zweite PPU 202 überträgt die Daten an den SM 310 auf der ersten PPU 202 mit einem Hinweis, der die Daten als fehlerhaft kennzeichnet. Der SM 310 leitet, wie hier beschrieben, eine Haltesequenz ein und identifiziert die Kontextausführung auf dem SM 310 in der ersten PPU 202 als den Kontext, bei dem der Speicherfehler aufgetreten ist. Der SM 310 in der ersten PPU 202 identifiziert die zweite PPU 202 als die Quelle des Speicherfehlers. Kein Kontext auf der zweiten PPU 202 wird angehalten oder neu gestartet.
  • Da Kontrollpunkte in dem Speicher 420, wie dem DRAM 220 oder dem L2-Cache 422, gespeichert werden, ist das Speichern und Laden von Kontrollpunkten im Vergleich zu früheren lokalen Kontrollpunkt- und Wiederherstellungsansätzen, die Kontrollpunkte in einem Dateisystem speichern, schneller. Das Speichern von Kontrollpunkten in dem Speicher 420, wie z. B. dem DRAM 220 oder dem L2-Cache 422, wird durch Einsetzen des hierin beschriebenen CILP-Mechanismus, um einen Schnappschuss des Mikroarchitektur-Status zu erstellen, ermöglicht. Zusätzlich werden lokale Kontrollpunkte während der Wiederherstellung des Kontrollpunkts getestet, um festzustellen, ob die Daten, die der Kontrollpunkt aufweist, einen nicht korrigierbaren ECC-Speicherfehler aufweisen. Wenn der lokale Kontrollpunkt einen Speicherfehler aufweist, hält die Wiederherstellung des Kontrollpunkts an, und ein früherer lokaler Kontrollpunkt wird wiederhergestellt oder alternativ wird ein globaler Kontrollpunkt wiederhergestellt. Auf diese Weise erkennen die vorgestellten Techniken auch Speicherfehler in Kontrollpunkten.
  • 5 ist ein Ablaufdiagramm von Verfahrensschritten zum Speichern lokaler Kontrollpunkte mittels der PPU 202 von 2, gemäß verschiedener Ausführungsformen. Obwohl die Verfahrensschritte in Verbindung mit den Systemen der 1-4 beschrieben werden, werden Fachleute verstehen, dass jedes System, das zur Durchführung der Verfahrensschritte in beliebiger Reihenfolge ausgestaltet ist, unter den Umfang der vorliegenden Offenbarung fällt.
  • Wie gezeigt, beginnt ein Verfahren 500 in Schritt 502, in dem ein Speicher-Client 430 einen oder mehrere Befehle ausführt. Der Speicher-Client 430 kann ein SM 310, ein globaler Konstant-Cache (GCC) 432, eine Kopiermaschine 434 oder ein Kontextwechsler 436 sein. In Schritt 504 stellt der Speicher-Client 430 fest, dass ein Zeitpunkt zum Speichern eines lokalen Kontrollpunkts fällig ist. Die Software, die auf dem Speicher-Client 430 ausgeführt wird, bestimmt, dass ein Zeitpunkt zum Speichern eines lokalen Kontrollpunkts fällig ist basierend auf a priori Daten bezüglich der Häufigkeit von Fehlern des Speicher-Clients 430, basierend auf einer adaptiven Überwachung von Speicherfehlern, basierend auf einer verstrichenen Zeitdauer, basierend auf einem Empfangen einer Unterbrechung und/oder anderen technisch möglichen Kriterien. In einigen Ausführungsformen kann sich die Häufigkeit der Speicherung lokaler Kontrollpunkte im Laufe der Zeit ändern.
  • In Schritt 506 führt der Speicher-Client 430 eine Operation zum Berechnen einer Unterbrechung auf Befehlsebene (Compute Instruction Level Preemption, CILP) durch. Die CILP-Operation hält die Ausführung des Speicher-Clients 430 an einer Befehlsgrenze an, um den Mikroarchitektur-Kontextstatus als Schnappschuss aufzunehmen oder zu erfassen. Die CILP-Operation unterbricht das Anwendungsprogramm, die Speicherkopieroperation und/oder andere Operationen, die hier als „Arbeit“ bezeichnet werden, die auf einem bestimmten SM 310 ausgeführt wird. In Schritt 508 speichert der SM 310 den Mikroarchitektur-Kontextstatus im lokalen Speicher, z. B. im L2-Cache 422, mit einer Granularität auf Befehlsebene. Der SM 310 speichert den Mikroarchitektur-Kontextstatus in einem lokalen Kontrollpunkt. Als Ergebnis wird der gespeicherte Mikroarchitektur-Kontextstatus zu einem lokalen Kontrollpunkt für diesen bestimmten Kontext. Über die CILP-Operation löst der SM 310 einen feingranularen Kontrollpunkt in einem beliebigen, von dem Software-Wiederherstellungstreiber gewählten Intervall aus. Als Ergebnis kann an einer beliebigen Befehlsgrenze eines Anwendungsprogramms oder einer anderen Arbeit, die auf dem SM 310 oder einem anderen Speicher-Client ausgeführt wird, eine CILP-Operation durchgeführt werden und ein lokaler Kontrollpunkt kann gespeichert werden. Das Verfahren 500 fährt dann mit dem oben beschriebenen Schritt 502 fort.
  • Nachfolgend kann der Speicher-Client einen Hinweis darauf erhalten, dass Daten, die einem Befehl zugeordnet sind, der eine von dem Speicher-Client ausgeführte Speicher-Ladeoperation aufweist, beschädigt sind. Als Reaktion auf das Empfangen des Hinweises leitet der Speicher-Client eine oder mehrere Halteoperationen für den Speicher-Client ein. Der Speicher-Client ruft den Mikroarchitektur-Kontextstatus von dem lokalen Kontrollpunkt ab. Der Speicher-Client setzt einen aktuellen Zustand des Speicher-Clients als den Mikroarchitektur-Kontextzustand.
  • 6 ist ein Ablaufdiagramm von Verfahrensschritten zum Verarbeiten eines Speicherfehlers mittels der PPU 202 von 2, gemäß verschiedener Ausführungsformen. Obwohl die Verfahrensschritte in Verbindung mit den Systemen der 1-4 beschrieben werden, werden Fachleute verstehen, dass ein beliebiges System, das zur Durchführung der Verfahrensschritte in beliebiger Reihenfolge ausgestaltet ist, unter den Umfang der vorliegenden Offenbarung fällt.
  • Wie gezeigt, beginnt ein Verfahren 600 mit Schritt 602, in dem ein Speicher-Client 430 einen Befehl ausführt, der eine Speicher-Ladeoperation aufweist. Der Speicher-Client 430 kann ein SM 310, ein globaler Konstant-Cache (GCC) 432, eine Kopiermaschine 434, ein Kontextwechsler 436 und/oder Ähnliches sein. Die Speicher-Ladeoperation kann auf Daten gerichtet sein, die sich in dem DRAM 220, dem L2-Cache 422, einem anderen Speicher 424 und/oder dergleichen befinden.
  • In Schritt 604 bestimmt eine Speichersteuerungslogik 405 oder eine andere Speichersteuerung, die die Speicher-Ladeoperation für den Speicher-Client 430 bedient, ob die Daten aus der Speicher-Ladeoperation beschädigt sind. Die Speichersteuerungslogik 405 stellt fest, dass die Daten beschädigt sind, basierend auf einem oder beiden ECC-Fehlern oder einem zuvor gespeicherten Giftmuster, das den Daten zugeordnet ist. Das Giftmuster ist ein spezifisches Bitmuster, das die Speichersteuerungslogik 405 in den Datengiftbits speichert, die den Daten zugeordnet sind. Wenn die Daten aus der Speicher-Ladeoperation nicht beschädigt sind, dann fährt das Verfahren mit Schritt 606 fort, wo der Speicher-Client 430 ein Ausführen von Befehlen fortsetzt. Das Verfahren 600 endet dann.
  • Zurück zu Schritt 604: Wenn die Daten aus der Speicher-Ladeoperation beschädigt sind, dann fährt das Verfahren 600 mit Schritt 608 fort, wo die Speichersteuerungslogik 405 das Giftmuster an den Speicher-Client 430 zurückgibt. In Schritt 610 deaktiviert der Speicher-Client 430 die Speicher-Einspeicheroperationen von dem Speicher-Client 430 und leitet eine oder mehrere Halteoperationen für den Speicher-Client 430 ein. Insbesondere deaktiviert der Speicher-Client 430 Speicherungen im Speicher, Speicherungen in Dateisystemen und andere Datenübertragungen von dem Speicher-Client 430, um zu verhindern, dass die beschädigten Daten andere Plätze des Speichers 420, Speicher-Clients 430 und/oder andere Komponenten der PPU 202 beeinträchtigen. Der Speicher-Client 430 leitet eine oder mehrere Halteoperationen ein, um weitere Speicher-Ladeoperationen und/oder Speicher-Einspeicheroperationen zu deaktivieren, einschließlich Speicherbarrieren und Kontextwechsel. Als Teil der Haltesequenz erzeugt und speichert der Speicher-Client 430 Fehlerprotokolldaten, die angeben, dass der Speicher-Client 430 aufgrund eines Speicherfehlers angehalten wurde, den Ort des Speicherfehlers, den Befehl, der zum Zeitpunkt des Speicherfehlers ausgeführt wurde, den Kontext und/oder Prozess, der zum Zeitpunkt des Speicherfehlers auf dem Speicher-Client 430 ausgeführt wurde, den Speicher-Client 430, der den Speicherfehler erkannt hat, und/oder Ähnliches. Ein Software-Wiederherstellungstreiber setzt das System zurück und analysiert die Fehlerprotokolldaten.
  • In Schritt 612 stellt der Software-Wiederherstellungstreiber den letzten lokalen Kontrollpunkt auf dem Speicher-Client 430 wieder her. Abhängig von dem Prozess und/oder Kontext, der zum Zeitpunkt des Speicherfehlers ausgeführt wurde, kann der Software-Wiederherstellungstreiber auch einen oder mehrere andere Speicher-Clients 430 auf den letzten lokalen Kontrollpunkt zurücksetzen. In Schritt 614 veranlasst der Software-Wiederherstellungstreiber den Speicher-Client 430 und andere betroffene Speicher-Clients 430, den Betrieb beginnend mit dem wiederhergestellten Kontrollpunkt wieder aufzunehmen. Dann endet das Verfahren 600.
  • 7 ist ein Ablaufdiagramm von Verfahrensschritten zum Auslagern einer Cache-Zeile, die einen Speicherfehler aufweist, gemäß verschiedener Ausführungsformen. Obwohl die Verfahrensschritte in Verbindung mit den Systemen der 1-4 beschrieben werden, werden Fachleute verstehen, dass jedes System, das zur Durchführung der Verfahrensschritte in beliebiger Reihenfolge ausgestaltet ist, unter den Umfang der vorliegenden Offenbarung fällt.
  • Wie gezeigt, beginnt ein Verfahren 700 mit Schritt 702, bei dem die einem Cache-Speicher zugeordnete Speichersteuerungslogik 405 bestimmt, dass eine Cache-Zeile aus dem Cache-Speicher ausgelagert werden soll. Der Cache-Speicher kann der L2-Cache 422, ein L1.5-Cache, ein L1-Cache und/oder dergleichen sein. In Schritt 704 stellt die Speichersteuerungslogik 405 fest, dass die Daten, die die auszulagernde Cache-Zeile aufweist, beschädigt sind. Die Speichersteuerungslogik 405 stellt fest, dass die Daten beschädigt sind, basierend auf einem oder beidem von einem ECC-Fehler oder einem vorher gespeicherten Giftmuster, das den Daten zugeordnet ist. In Schritt 706 schreibt die Speichersteuerungslogik 405 Daten aus der Cache-Zeile in den DRAM 220 oder einen anderen geeigneten Speicher, zusammen mit einem Giftmuster, das anzeigt, dass die Daten in der Cache-Zeile beschädigt sind. Wenn die in dem DRAM 220 gespeicherte Cache-Zeile anschließend wieder in den Cache-Speicher geladen wird, identifiziert daher das Giftmuster die Daten in der Cache-Zeile basierend auf einem zuvor gespeicherten Giftmuster, das den Daten zugeordnet ist, als beschädigt. Das Verfahren 700 endet dann.
  • Zusammenfassend weisen verschiedene Ausführungsformen eine GPU auf, die einen feingranularen lokalen Kontrollpunkt und eine Wiederherstellung an Befehlsebenengrenzen von Speicher-Clients innerhalb der GPU durchführt. Ein Softwaretreiber speichert periodisch lokale Kontrollpunkte für die Speicher-Clients in der GPU. Genauer gesagt nutzt ein Software-Wiederherstellungstreiber die Funktion zum Berechnen einer Unterbrechung auf Befehlsebene (Compute Instruction Level Preemption, CILP) der GPU, um die Ausführung an einer GPU-Programmbefehlsgrenze anzuhalten. Wenn die Speicher-Clients innerhalb der GPU angehalten haben, speichert der Software-Wiederherstellungstreiber einen Kontrollpunkt, der den Mikroarchitektur-Status der Speicher-Clients aufweist. Wenn ein Speicher-Client einen Speicherfehler erfasst, verhindert der Speicher-Client, dass weitere Daten von dem Speicher-Client gespeichert oder an das Speichersystem übertragen werden, wodurch verhindert wird, dass sich der Speicherfehler auf andere Speicher-Clients, auf andere GPUs oder auf die CPU ausbreitet. Der Speicher-Client blockiert auch Kontextwechsel und Speicherbarrieren, um den Speicherfehler einzudämmen. Der Speicher-Client leitet eine oder mehrere Halteoperationen ein, um Befehle aus den Befehlswarteschlangen des Speicher-Clients zu entfernen, um alle anhängigen Speicheroperationen zu löschen. Als Ergebnis bewahrt der Speicher-Client die Integrität des vorherigen lokalen Kontrollpunkts, wodurch dem Software-Wiederherstellungstreiber ermöglicht wird, zuverlässig vom vorherigen lokalen Kontrollpunkt neu zu starten. Der Speicher-Client speichert Fehlerprotokolldaten, die Daten aufweisen, die dem Speicherfehler zugeordnet sind, benachrichtigt den Software-Wiederherstellungstreiber und hält an. Der Software-Wiederherstellungstreiber greift dann auf die Fehlerprotokolldaten zu, um die Art des Speicherfehlers zu ermitteln, stellt den vorherigen lokalen Kontrollpunkt wieder her und startet den angehaltenen Speicher-Client neu.
  • Mindestens ein technischer Vorteil der offenbarten Techniken im Vergleich zum Stand der Technik ist, dass mit den offenbarten Techniken ein lokaler Kontrollpunkt und eine Wiederherstellung mit feinerer Granularität im Vergleich zu früheren Ansätzen durchgeführt werden. Wenn ein Speicher-Client innerhalb einer GPU einen Speicherfehler feststellt, wird nur der betroffene Speicher-Client angehalten, der letzte lokale Kontrollpunkt wird in den Speicher-Client geladen, und der Speicher-Client setzt die Ausführung ab dem letzten lokalen Kontrollpunkt fort. Ferner werden ein lokaler Kontrollpunkt und eine Wiederherstellung durch die GPU und für jeden Speicher-Client eingerichtet, was zu einer schnelleren Erkennung von Speicherfehlern führt, die während einer Ausführung des GPU-Programms auftreten. Ein anderer technischer Vorteil der offenbarten Techniken ist, dass, wenn ein Speicher-Client innerhalb der GPU einen Speicherfehler feststellt, der Speicher-Client daran gehindert wird, Daten zu speichern oder anderweitig an andere Speicherplätze, andere Speicher-Clients in der GPU, andere GPUs oder die CPU nach außen zu übertragen. Als Ergebnis wird die Wahrscheinlichkeit, dass ein in einer GPU auftretender Speicherfehler sich auf andere Teile des OS-Knotens oder auf andere OS-Knoten ausbreitet, im Vergleich zu früheren Ansätzen verringert. Diese Vorteile stellen eine oder mehrere technologische Verbesserungen gegenüber den Ansätzen des Standes der Technik dar.
  • Alle Kombinationen von beliebigen Anspruchselementen, die in den Ansprüchen aufgeführt sind, und/oder von Elementen, die in dieser Anmeldung beschrieben sind, fallen in beliebiger Weise in den vorgesehenen Umfang der vorliegenden Offenbarung und des Schutzes.
  • Die Beschreibungen der verschiedenen Ausführungsformen wurden zum Zwecke der Veranschaulichung dargestellt, sind jedoch nicht dazu gedacht, erschöpfend oder auf die offengelegten Ausführungsformen beschränkt zu sein. Viele Modifikationen und Variationen werden für den Fachmann offensichtlich sein, ohne von dem Umfang und dem Sinn der beschriebenen Ausführungsformen abzuweichen.
  • Aspekte der vorliegenden Ausführungsformen können als System, Verfahren oder Computerprogrammprodukt ausgeführt werden. Dementsprechend können Aspekte der vorliegenden Offenbarung die Form einer reinen Hardware-Ausführungsform, einer reinen Software-Ausführungsform (einschließlich Firmware, residenter Software, Mikrocode usw.) oder einer Ausführungsform aufweisen, die Software- und Hardware-Aspekte kombiniert, die hier alle allgemein als „Modul“ oder „System“ bezeichnet werden können. Des Weiteren können Aspekte der vorliegenden Offenbarung die Form eines Computerprogrammprodukts annehmen, das in einem oder mehreren computerlesbaren Medium(en) mit darauf ausgeführtem computerlesbarem Programmcode ausgeführt ist.
  • Eine beliebige Kombination von einem oder mehreren computerlesbaren Medium(en) kann verwendet werden. Das computerlesbare Medium kann ein computerlesbares Signalmedium oder ein computerlesbares Speichermedium sein. Ein computerlesbares Speichermedium kann beispielsweise, aber ist nicht beschränkt auf, ein elektronisches, magnetisches, optisches, elektromagnetisches, infrarotes oder Halbleitersystem, -apparat oder -gerät sein, oder jede geeignete Kombination der vorgenannten. Spezifischere Beispiele (eine nicht erschöpfende Liste) für das computerlesbare Speichermedium können Folgendes aufweisen: eine elektrische Verbindung mit einem oder mehreren Drähten, eine tragbare Computerdiskette, eine Festplatte, einen Direktzugriffsspeicher (RAM), einen Nur-Lese-Speicher (ROM), einen löschbaren programmierbaren Nur-Lese-Speicher (EPROM oder Flash-Speicher), eine optische Faser, einen tragbaren Compact-Disc-Nur-Lese-Speicher (CD-ROM), eine optische Speichervorrichtung, eine magnetische Speichervorrichtung oder irgendeine geeignete Kombination der vorgenannten. Im Zusammenhang mit diesem Dokument kann ein computerlesbares Speichermedium jedes greifbare Medium sein, das ein Programm zur Verwendung durch oder in Verbindung mit einem Befehlsausführungssystem, - apparat oder -gerät enthalten oder speichern kann.
  • Aspekte der vorliegenden Offenbarung wurden oben unter Bezugnahme auf Ablaufdiagrammdarstellungen und/oder Blockdiagramme von Verfahren, Vorrichtungen (Systemen) und Computerprogrammprodukten gemäß der Ausführungsformen der Offenbarung beschrieben. Es versteht sich, dass jeder Block der Ablaufdiagrammdarstellungen und/oder Blockdiagramme und Kombinationen von Blöcken in den Ablaufdiagrammdarstellungen und/oder Blockdiagrammen durch Computerprogrammbefehle implementiert werden können. Diese Computerprogrammbefehle können einem Prozessor eines Allzweckcomputers, eines Spezialcomputers oder einer anderen programmierbaren Datenverarbeitungsvorrichtung bereitgestellt werden, um eine Maschine zu erzeugen, so dass die Befehle, die über den Prozessor des Computers oder der anderen programmierbaren Datenverarbeitungsvorrichtung ausgeführt werden, die Implementierung der Funktionen/Aktionen ermöglichen, die in dem Flussdiagramm- und/oder Blockdiagrammblock oder den Blöcken angegeben sind. Solche Prozessoren können, ohne Einschränkung, Allzweckprozessoren, Spezialprozessoren, anwendungsspezifische Prozessoren oder feldprogrammierbare Gatteranordnungen sein.
  • Die Ablaufdiagramme und Blockdiagramme in den Figuren veranschaulichen die Architektur, die Funktionalität und den Betrieb möglicher Implementierungen von Systemen, Verfahren und Computerprogrammprodukten gemäß verschiedener Ausführungsformen der vorliegenden Offenbarung. In dieser Hinsicht kann jeder Block in den Ablaufdiagrammen oder den Blockdiagrammen ein Modul, ein Segment oder einen Teil eines Codes darstellen, der einen oder mehrere ausführbare Befehle zur Implementierung der angegebenen logischen Funktion(en) umfasst. Es sollte auch beachtet werden, dass in einigen alternativen Implementierungen die in den Blöcken angegebenen Funktionen in einer anderen Reihenfolge als in den Figuren angegeben auftreten können. Zum Beispiel können zwei Blöcke, die nacheinander gezeigt sind, tatsächlich im Wesentlichen gleichzeitig ausgeführt werden, oder die Blöcke können manchmal in umgekehrter Reihenfolge ausgeführt werden, abhängig von der beteiligten Funktionalität. Es wird auch darauf hingewiesen, dass jeder Block der Blockdiagramme und/oder Ablaufdiagrammdarstellungen und Kombinationen von Blöcken in den Blockdiagrammen und/oder Ablaufdiagrammdarstellungen durch Hardwarebasierte Spezialsysteme, die die angegebenen Funktionen oder Handlungen ausführen, oder Kombinationen von Spezialhardware und Computerbefehlen implementiert werden können.
  • Obwohl sich das Vorstehende auf Ausführungsformen der vorliegenden Offenbarung bezieht, können andere und weitere Ausführungsformen der Offenbarung entworfen werden, ohne von dem grundlegenden Umfang derselben abzuweichen, und der Umfang derselben wird durch die folgenden Ansprüche bestimmt.

Claims (18)

  1. Computerimplementiertes Verfahren zum Verarbeiten eines Speicherfehlers, wobei das Verfahren umfasst: Bewirken, dass ein erster Befehl, der eine Speicher-Ladeoperation aufweist, von einem ersten Speicher-Client ausgeführt wird, der in mehreren Speicher-Clients enthalten ist; Empfangen eines Hinweises, dass Daten, die der Speicher-Ladeoperation zugeordnet sind, beschädigt sind; und abhängig von dem Empfangen des Hinweises: Deaktivieren des ersten Speicher-Clients für ein Durchführen von Speicher-Ladeoperationen, und Einleiten einer oder mehrerer Halteoperationen für den ersten Speicher-Client, wobei ein zweiter Speicher-Client, der in den mehreren Speicher-Clients enthalten ist, fortfährt, Befehle auszuführen, während der erste Speicher-Client deaktiviert ist.
  2. Computerimplementiertes Verfahren nach Anspruch 1, wobei der Hinweis, dass der Speicher-Ladeoperation zugeordnete Daten beschädigt sind, auf einem Bitmuster basiert, das in einem Speicherwort, das die Daten aufweist, enthalten ist.
  3. Computerimplementiertes Verfahren nach Anspruch 1 oder 2, wobei der Hinweis, dass der Speicher-Ladeoperation zugeordnete Daten beschädigt sind, auf einem Fehlerkorrekturcode basiert, der in einem Speicherwort, das die Daten aufweist, enthalten ist.
  4. Computerimplementiertes Verfahren nach einem der vorhergehenden Ansprüche, wobei das Einleiten der einen oder mehreren Halteoperationen ein Leeren eines oder mehrerer Befehle aus einer Befehlswarteschlange umfasst, die in dem ersten Speicher-Client enthalten ist.
  5. Computerimplementiertes Verfahren nach einem der vorhergehenden Ansprüche, wobei das Einleiten der einen oder mehreren Halteoperationen ein Speichern von dem Speicherfehler zugeordneten Fehlerprotokolldaten umfasst.
  6. Computerimplementiertes Verfahren nach Anspruch 5, wobei die Fehlerprotokolldaten eines oder mehr anzeigen von: einem Ort des Speicherfehlers, dem ersten Befehl, einem auf dem ersten Speicher-Client ausgeführten Kontext oder dem ersten Speicher-Client.
  7. Computerimplementiertes Verfahren nach einem der vorhergehenden Ansprüche, wobei das Einleiten der einen oder mehreren Halteoperationen umfasst: Benachrichtigen eines Softwaretreibers über den Speicherfehler; und Anhalten des ersten Speicher-Clients.
  8. Computerimplementiertes Verfahren nach Anspruch 7, wobei das Einleiten der einen oder mehreren Halteoperationen ein Neustarten des ersten Speicher-Clients umfasst, um einen zweiten Befehl auszuführen, der dem ersten Befehl vorausgeht.
  9. Computerimplementiertes Verfahren nach einem der vorhergehenden Ansprüche, wobei der erste Befehl die Daten in einem Konstant-Cache-Speicher speichert.
  10. Computerimplementiertes Verfahren nach einem der vorhergehenden Ansprüche, wobei der erste Befehl in einer Blockkopieroperation enthalten ist.
  11. Computerimplementiertes Verfahren nach einem der vorhergehenden Ansprüche, wobei der erste Befehl in einer Kontextaustauschoperation enthalten ist.
  12. Computerimplementiertes Verfahren nach einem der vorhergehenden Ansprüche, ferner umfassend: Speichern eines Bitmusters, das anzeigt, dass die der Speicher-Ladeoperation zugeordneten Daten beschädigt sind; Laden der Daten und des Bitmusters von einer ersten Adresse; und Speichern der Daten und des Bitmusters an einer zweiten Adresse.
  13. Ein oder mehrere nicht flüchtige computerlesbare Medien, die Programmbefehle speichern, die, wenn sie von einem oder mehreren Prozessoren ausgeführt werden, den einen oder die mehreren Prozessoren veranlassen, Schritte eines Verfahrens nach einem der Ansprüche 1 bis 12 auszuführen.
  14. System, umfassend: einen Speicher, der Befehle speichert; und einen Prozessor, der mit dem Speicher gekoppelt ist und, wenn er die Befehle ausführt: veranlasst, dass ein erster Befehl, der eine Speicher-Ladeoperation aufweist, von einem ersten Speicher-Client ausgeführt wird, der in mehreren Speicher-Clients enthalten ist; einen Hinweis empfängt, dass Daten, die der Speicher-Ladeoperation zugeordnet sind, beschädigt sind; und als Reaktion auf den Empfang des Hinweises: den ersten Speicher-Client für die Durchführung von Speicher-Ladeoperationen sperrt, und eine oder mehrere Halteoperationen für den ersten Speicher-Client einleitet, wobei ein zweiter Speicher-Client, der in den mehreren Speicher-Clients enthalten ist, fortfährt, Befehle auszuführen, während der erste Speicher-Client gesperrt ist.
  15. Computer-implementiertes Verfahren zum Verarbeiten eines Speicherfehlers, wobei das Verfahren umfasst: Bestimmen, dass ein Zeitpunkt zum Speichern eines lokalen Kontrollpunktes für einen Speicher-Client fällig ist; Anhalten einer Ausführung des Speicher-Clients an einer Befehlsgrenze; Erfassen eines Mikroarchitektur-Kontextstatus des Speicher-Clients; und Speichern des Mikroarchitektur-Kontextstatus in dem lokalen Kontrollpunkt.
  16. Computer-implementiertes Verfahren nach Anspruch 15, ferner umfassend: Empfangen eines Hinweises, dass Daten, die einem Befehl zugeordnet sind, der eine von dem Speicher-Client ausgeführte Speicher-Ladeoperation aufweist, beschädigt sind; und abhängig von dem Empfangen des Hinweises: Einleiten einer oder mehrerer Halteoperationen für den Speicher-Client, Abrufen des Mikroarchitektur-Kontextstatus von dem lokalen Kontrollpunkt, und Einstellen eines aktuellen Zustands des Speicher-Clients als den Mikroarchitektur-Kontextstatus.
  17. Computerimplementiertes Verfahren nach Anspruch 15 oder 16, ferner umfassend: Veranlassen, dass ein erster Befehl, der eine Speicher-Ladeoperation aufweist, ausgeführt wird, wobei die Speicher-Ladeoperation einer virtuellen Adresse zugeordnet ist; Empfangen, mittels einer Speicherverwaltungseinheit, eines Hinweises, dass ein der virtuellen Adresse zugeordneter Übersetzungspuffer(TLB)-Eintrag beschädigt ist; Aktualisieren des TLB-Eintrags basierend auf einem oder mehreren Seitentabelleneinträgen, die der virtuellen Adresse zugeordnet sind; Bestimmen, dass der Mikroarchitektur-Kontextstatus in dem lokalen Kontrollpunkt nicht wiederhergestellt werden muss; und Zurückgeben einer der virtuellen Adresse zugeordneten physikalischen Adresse an den Speicher-Client.
  18. Computerimplementiertes Verfahren nach Anspruch 17, ferner umfassend: Veranlassen, dass ein erster Befehl, der eine Speicher-Ladeoperation aufweist, ausgeführt wird, wobei die Speicher-Ladeoperation einer virtuellen Adresse zugeordnet ist; Empfangen, mittels einer Speicherverwaltungseinheit, eines Hinweises, dass ein der virtuellen Adresse zugeordneter Seitentabelleneintrag beschädigt ist; Bestimmen, dass der Mikroarchitektur-Kontextstatus in dem lokalen Kontrollpunkt nicht wiederhergestellt werden muss; und Zurückgeben einer negativen Bestätigung, die der virtuellen Adresse zugeordnet ist, an den Speicher-Client.
DE102022116706.2A 2021-07-12 2022-07-05 Fehlereingrenzung zum ermöglichen eines lokalen kontrollpunkts und einer wiederherstellung Pending DE102022116706A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US17/373,678 US11720440B2 (en) 2021-07-12 2021-07-12 Error containment for enabling local checkpoint and recovery
US17/373,678 2021-07-12

Publications (1)

Publication Number Publication Date
DE102022116706A1 true DE102022116706A1 (de) 2023-01-12

Family

ID=84533907

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102022116706.2A Pending DE102022116706A1 (de) 2021-07-12 2022-07-05 Fehlereingrenzung zum ermöglichen eines lokalen kontrollpunkts und einer wiederherstellung

Country Status (3)

Country Link
US (1) US11720440B2 (de)
CN (1) CN115599594A (de)
DE (1) DE102022116706A1 (de)

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5295258A (en) * 1989-12-22 1994-03-15 Tandem Computers Incorporated Fault-tolerant computer system with online recovery and reintegration of redundant components
US6530036B1 (en) * 1999-08-17 2003-03-04 Tricord Systems, Inc. Self-healing computer system storage
US6848063B2 (en) * 2001-11-20 2005-01-25 Hewlett-Packard Development Company, L.P. System and method for scrubbing errors in very large memories
US7320100B2 (en) * 2003-05-20 2008-01-15 Cray Inc. Apparatus and method for memory with bit swapping on the fly and testing
US7540026B1 (en) * 2005-01-24 2009-05-26 Symantec Corporation No-execute processor feature global disabling prevention system and method
US20130124838A1 (en) 2011-11-10 2013-05-16 Lacky V. Shah Instruction level execution preemption
US9336144B2 (en) * 2013-07-25 2016-05-10 Globalfoundries Inc. Three-dimensional processing system having multiple caches that can be partitioned, conjoined, and managed according to more than one set of rules and/or configurations
US10664181B2 (en) * 2017-11-14 2020-05-26 International Business Machines Corporation Protecting in-memory configuration state registers
US11113783B2 (en) * 2019-11-13 2021-09-07 Intel Corporation Programmable re-order buffer for decompression

Also Published As

Publication number Publication date
US11720440B2 (en) 2023-08-08
CN115599594A (zh) 2023-01-13
US20230011863A1 (en) 2023-01-12

Similar Documents

Publication Publication Date Title
US10649853B2 (en) Tracking modifications to a virtual machine image that occur during backup of the virtual machine
US9058195B2 (en) Virtual machines failover
DE102013218341B4 (de) Ersatzweise Verlagerung von Threads (Thread-Sparing) zwischen Berechnungskernen in einem Multithread-Prozessor
DE102020122182A1 (de) Virtuelle-maschine-replikation und -migration
DE112007001171T5 (de) Verfahren für virtualisierten Transaktionsspeicher bei globalem Überlauf
CN109997118B (zh) 在永久存储器系统中以超高速一致地存储大量数据的方法
US20150378770A1 (en) Virtual machine backup
DE102013200503A1 (de) Virtualisierungs-Support zum Speichern und Wiederherstellen von Zuständen einer Sprungvorhersage-Logik
DE102012224265A1 (de) Gemeinsame Nutzung dicht benachbarter Daten-Cachespeicher
US10339009B2 (en) System for flagging data modification during a virtual machine backup
DE112014002754T5 (de) Effiziente Aufgabenplanung unter Verwendung eines Sperrmechanismus
DE112015001502T5 (de) Ausstieg aus mehreren Threads in einem Computer
DE102013209643A1 (de) Mechanismus für optimierte Nachrichtenaustauschdatenübertragung zwischen Nodelets innerhalb eines Plättchens
DE102014003687A1 (de) Vorrichtung und verfahren zum schutz von digitalem inhalt
US20170091254A1 (en) Making volatile isolation transactions failure-atomic in non-volatile memory
DE102012220365A1 (de) Aufgabe-Thread-Feld-Granularität-Ausführung-Präemption
DE102020128675A1 (de) Puffer zum verringern von schreibverstärkung fehlausgerichteter schreiboperationen
DE102022116706A1 (de) Fehlereingrenzung zum ermöglichen eines lokalen kontrollpunkts und einer wiederherstellung
DE102022112459A1 (de) Techniken zum effizienten synchronisieren mehrerer programmthreads
DE102013021996A1 (de) Wiederholung von Speichertransaktionen während der Behandlung von Speicherzugriffsfehlern
DE102021105247A1 (de) Techniken zum effizienten organisieren und zugreifen auf komprimierbare daten
DE102022116841A1 (de) Thread-synchronisation über speicher-synchronisationsdomains hinweg
DE102022129589A1 (de) Direkte übermittlung von arbeit im benutzermodus in prozessoren mit befähigung für sicheres rechnen
DE102022116839A1 (de) Programmierbare zustandsmaschine für einen hardwareleistungsmonitor
DE102023133534A1 (de) Mit tags versehene aliasfreie fehlerkorrekturcodes für maschinenspeicheroperationen

Legal Events

Date Code Title Description
R012 Request for examination validly filed