DE102010035603A1

DE102010035603A1 - Bereitstellen von Hardwareunterstützung für gemeinsam benutzten virtuellen Speicher zwischen physischem Lokal- und Fernspeicher

Info

Publication number: DE102010035603A1
Application number: DE102010035603A
Authority: DE
Inventors: Gautham N. Hillsboro Chinya; Ethan Santa Clara Schuchman; Hong Fremont Wang; James P. Portland Held; Deepak A. Santa Clara Mathaikutty; Ajay V. Portland Bhatt; Jamison D. San Jose Collins; Prashant Folsom Sethi; Stephen F. Phoenix Whalley
Original assignee: Intel Corp
Current assignee: Intel Corp
Priority date: 2009-09-18
Filing date: 2010-08-27
Publication date: 2011-04-07
Also published as: TWI470435B; CN102023932A; CN104123242A; JP2015135696A; JP5911985B2; BRPI1003466A2; US20110072234A1; CN102023932B; US8719547B2; US9003164B2; US20140208042A1; TW201120643A; CN104123242B; JP2011065650A; JP2013254524A

Abstract

Bei einer Ausführungsform beinhaltet die vorliegende Erfindung eine Speichermanagementeinheit (memory management unit, MMU) mit Einträgen, um Übersetzungen von virtuellen Adressen in physische Adressen zu speichern, wobei jeder Eintrag einen Ortsindikator beinhaltet, um anzuzeigen, ob ein Speicherort für den entsprechenden Eintrag in einem Lokal- oder Fernspeicher vorhanden ist. Auf diese Art und Weise kann ein herkömmlicher virtueller Speicherraum zwischen den beiden Speichern, die durch eine oder mehr nicht-kohärente Verbindungen getrennt sein können, gemeinsam benutzt werden. Weitere Ausführungsformen sind beschrieben und werden beansprucht.

Description

Hintergrund
Da prozessorbasierte Systeme weiterentwickelt werden, ermöglicht die Verfügbarkeit von programmierbaren Beschleunigern, die mit dem System über eine periphere Hochgeschwindigkeitskopplungsstruktur verbunden sind, wie z. B. eine Peripheral Component Interconnect Express (PCIe^TM) Kopplungsstruktur, in Übereinstimmung mit Verbindungen, basierend auf der PCI Express Spezification Base Spezifikation Version 2.0 (veröffentlicht am 17. Januar 2007) (nachstehend die PCIe^TM Spezifikation) oder einem anderes solches Protokoll, Systemintegratoren, eine höhere Rechenleistung in ein System zu packen. Es bestehen jedoch Herausforderungen zu gewährleisten, dass eine Anwendung die zusätzliche Rechenleistung transparent einsetzen kann, ohne wesentliche Änderungen an der Anwendung vorzunehmen, um die Berechnung zwischen einem Hauptprozessor (z. B. Mehrkern-Hauptprozessor (multicore central processing unit, CPU) und dem/den Beschleuniger(n) manuell aufzuteilen und ein Hin- und Herverschieben von Daten zu verwalten. Traditionell steht nur der Hauptsystemspeicher, der vom Betriebssystem (operating system, OS) verwaltet wird, für zu verwendende Anwendungen zur Verfügung. Der physische Speicher, der sich lokal zu jedem Beschleuniger befindet und über eine periphere Kopplungsstruktur gekoppelt ist, wird separat verwaltet. Insbesondere ist solch ein Lokalspeicher auf dem Beschleuniger nicht als Teil des Systemspeichers sichtbar, der vom OS, das auf dem Hauptprozessor läuft, erkennbar ist. Stattdessen ist Gerätetreibersoftware dafür verantwortlich, die Datenverschiebung zwischen Lokal- und Fernspeicher ausdrücklich zu verwalten.
Der physische Speicher, auf den der Prozessor zugreift, wird vom Betriebssystem verwaltet, das einen Zugriff auf diesen physischen Speicher virtualisiert, um einen angrenzenden großen virtuellen Adressraum vorzutäuschen. Das OS verwendet zugrundeliegende Prozessorunterstützung für die Verwaltung des virtuellen Speichers, da der Prozessor der Software ermöglicht, eine Zuordnungstabelle zu erstellen, um virtuelle Seiten physischen Seiten zuzuordnen. Der Prozessor unterstützt eine Übersetzung von virtuellen Speicheradressen indem jedes Mal, wenn ein Speicherzugriff erfolgen soll, die Zuordnungstabelle herangezogen wird. Übersetzungen, auf die oft zugegriffen wird, können vom Prozessor im Cache gespeichert werden, um diesen Vorgang zu beschleunigen. Diese Zuordnungstabellen, herkömmlich als Seitentabellen bezeichnet, beinhalten ebenfalls Attribut-Bits, wie z. B. Lese-/Schreib- und Benutzer-/Supervisor-Privileg-Bits, die den Zugriff auf eine gegebene virtuelle Seite steuern. Während das OS den physischen Speicher verwaltet, der auf der Hauptplatine (der Systemspeicher) verfügbar ist, verwaltet es keinen lokal zu einem Beschleuniger befindlichen und dort verfügbaren Speicher oder weist keinen solchen Speicher zu. Somit erzeugen derzeitige Lösungen ein Model mit gemeinsam benutztem Speicher, aus Sicht des Programmierers, und sind abhängig von Speicherschutzmechanismen, um Seiten zu stören und diese zwischen unterschiedlichen Speichern hin- und herzuverschieben.
Kurze Beschreibung der Zeichnungen
1 ist ein Blockdiagramm eines Systems gemäß einer Ausführungsform der vorliegenden Erfindung.
2 ist ein Ablaufdiagramm eines Verfahrens zur Reverse Proxy Execution gemäß einer Ausführungsform der vorliegenden Erfindung.
3 ist ein Blockdiagramm, das Reverse Proxy Execution-Operationen gemäß einer Ausführungsform der vorliegenden Erfindung. veranschaulicht.
4 ist ein Ablaufdiagramm eines Verfahrens zur Proxy Execution gemäß einer Ausführungsform der vorliegenden Erfindun.
5 ist ein Blockdiagramm, das Proxy Execution-Operationen gemäß einer Ausführungsform der vorliegenden Erfindung veranschaulicht.
6 ist ein beispielhafter Eintrag einer Seitentabelle gemäß einer Ausführungsform der vorliegenden Erfindung.
7 ist ein Blockdiagramm eines Prozessors gemäß einer Ausführungsform der vorliegenden Erfindung.
8 ist ein Blockdiagramm eines Systems, einschließlich auf dem Chip integrierten Beschleunigern, gemäß einer Ausführungsform der vorliegenden Erfindung.
Ausführliche Beschreibung
Ausfhrungsformen ermöglichen es einem Prozessor (z. B. einem Hauptprozessor (central processing unit, CPU) auf einem Sockel), einen vollständig gemeinsam benutzten virtuellen Adressraum mit Beschleunigern, die mit dem System über eine Schnittstelle, z. B. eine Peripheral Component Interconnect Express (PCIe^TM) Schnittstelle, verbunden sind, zu erzeugen und zu verwalten, indem auf einen Speicher, der auf dem Beschleuniger vorhanden ist, zugegriffen wird und indem der Speicher unter Verwendung spezieller Lade-/Speicher-Transaktionen adressiert wird. Die Fähigkeit, Fernspeicher direkt zu adressieren, ermöglicht eine Steigerung der tatsächlichen Rechenkapazität, aus Sicht der Anwendungssoftware, und ermöglicht es Anwendungen, Daten problemlos gemeinsam zu benutzen, ohne dass der Programmierer beim Hin- und Herverschieben von Daten die ausdrückliche beteiligt ist. Somit kann der Speicher adressiert werden, ohne auf Speicherschutz zurückgreifen zu müssen und einen Zugriff auf eine virtuelle Adresse zu stören, um den Speicherzugriff, der von einem Störungsverarbeiter ausgeführt werden soll, umzuadressieren. Als solches kann bestehende gemeinsam benutzte Speicher-Mehrkernverarbeitung derart erweitert werden, dass Beschleuniger beinhaltet sind, die sich nicht auf dem Sockel befinden, sondern stattdessen über eine periphere nicht-kohärente Verbindung verbunden sind.
Im Gegensatz dazu erzeugen typische Systeme, wie z. B. clusterbasierte Systeme, ein Model eines teilweise gemeinsam benutzen Speichers, aus Sicht des Programmierers, und sind abhängig von Speicherschutzmechanismen, um Seiten zu stören und diese zwischen CPU und Peripheriegeräten hin- und herzuverschieben. Ebenfalls führt bei clusterbasierten Systemen jeder Knoten eine separate Kopie des Betriebssystem-(OS)-Stapels aus, auf dem eine Anwendung ausgeführt wird, und dieser Aspekt des Systems wird Programmierern offengelegt, da nur ein Teil des Adressraums gemeinsam benutzt wird und der Programmierer entweder aus einem gemeinsam benutzten Bereich zuteilt oder ausdrücklich spezifiziert, welcher Teil der Daten in dem gemeinsam benutzten Adressraum platziert wird. Die Ausführungsumgebung unterscheidet sich von einer Ausführungsumgebung mit vollständig gemeinsam benutztem Speicher, die einem Multikernsystem mit einem einzelnen gemeinsam benutzten Speicher ähnelt.
Stattdessen kann bei verschiedenen Ausführungsformen ein Prozessor auf einem Sockel Fernspeicher adressieren, der sich lokal zu einem Beschleuniger befindet, wodurch es dem Prozessor ermöglicht wird, Fernspeicheradressen transparent zu nutzen, um auf gemeinsam benutzte Daten zuzugreifen. Um dies auszuführen, können Architekturerweiterungen bereitgestellt werden, die eine Verbesserung eines virtuellen Speichermanagementsystems ermöglichen, sodass spezielle Lade-/Speicher-Transaktionen ausgegeben werden können, um entfernte gemeinsam benutzte Daten zu adressieren, und um dem System weiter zu ermöglichen, Speicherseiten näher an den Ort zu verschieben, von wo aus häufiger auf sie zugegriffen wird, ohne dass eine ausdrückliche Beteiligung des Programmierers hierfür erforderlich ist. Zusätzlich ermöglichen es Speichermanagementerweiterungen dem Programmierer, Anwendungscode direkt auszuführen, ohne dass ausdrücklich angegeben werden muss, welche Teile des Adressraums gemeinsam benutzt werden müssen, oder dass der Programmierer einen herkömmlichen gemeinsam benutzten Datenbereich verwalten muss.
Als solches kann ein gemeinsam benutzter virtueller Adressraum zwischen Kernen auf cachekohärenten CPU-Sockeln und Beschleunigern (einschließlich Mehrkern-CPUs), die mit dem System über eine periphere Kopplungsstruktur verbunden sind, erzeugt und verwaltet werden. Somit können CPUs/Beschleuniger auf beiden Seiten der Kopplungsstruktur auf eine gemeinsam benutzte virtuelle Seite, die sich physisch in einem Systemspeicher oder in einem Speicher befinden kann, der sich auf dem Beschleuniger befindet, über eine Kopplungsstruktur, die cachekohärent sein kann oder nicht, zugreifen.
Demnach kann der physische Speicher, der sich auf dem Beschleuniger befindet, gegenüber der CPU und wiederum gegenüber dem OS und Anwendungen als zusätzlicher Systemspeicher agieren, obwohl auf den Lokalspeicher des Beschleunigers über eine Kopplungsstruktur und nicht über eine kohärente Struktur (wie z. B. ein Frontside-Bus (front side bus, FSB) oder eine Quick-Path-Kopplungsstruktur (quick path interconnect, QPI) direkt von der CPU zugegriffen werden kann.
Ausführungsformen können in vielen unterschiedlichen Arten von Systemen implementiert sein. Es wird Bezug genommen auf 1, die ein Blockdiagramm eines Systems gemäß einer einer Ausführungsform der vorliegenden Erfindung zeigt. Wie in 1 gezeigt, kann System 100 ein beispielhaftes Computersystem mit einer Host-PC-(host personal computer, PC)-Plattform 110 sein, die mit einer Beschleunigerkarte 150 über eine nicht-kohärente Kopplungsstruktur 140 verbunden ist, die beispielsweise eine PCIe^TM-Verbindung sein kann. Wie gezeigt, kann Host-Plattform 110 eine CPU 120 und einen Systemspeicher 130 beinhalten, der bei einigen Ausführungsformen ein dynamischer Direktzugriffsspeicher (dynamic random access memory, DRAM) sein kann. Während der Einfachheit halber in 1 lediglich diese minimalen Komponenten gezeigt sind, ist es selbstverständlich, dass eine gegebene Plattform viele weitere typische Komponenten beinhalten kann, einschließlich Eingangs-/Ausgangs-Hubs, Chipsatz-Komponenten, Peripheriegeräte, Massenspeichergeräte, Eingabe-/Ausgabegeräte und so weiter.
Wie in 1 gezeigt, kann CPU 120 eine Speichermanagementeinheit (memory management unit, MMU) 125 beinhalten. MMU 125 kann ein Zuordnen von virtuellen Adressen zu physischen Adressen ermöglichen und kann bei einigen Implementierungen ein oder mehr Translation Lookaside-Puffer (translation lookaside buffers, TLBs) beinhalten. Wie nachstehend weiter erörtert wird, können verschiedene Architekturerweiterungen einer MMU gemäß einer erfindungsgemäßen Ausführungsform das Erzeugen und Verwenden eines gemeinsam benutzten virtuellen Speichers zwischen Speichern ermöglichen, die mit Plattform 110 und Beschleunigerkarte 150 verbunden sind.
Unter der weiteren Bezugnahme auf 1, kann Beschleunigerkarte 150 einen Intellectual Property-(intellectual property, IP)-Block 160 beinhalten, der jede Art Beschleuniger sein kann, wie z. B. ein Graphikprozessor, CPU oder jedes andere solche Gerät. Wie gezeigt, kann dieser IP-Block selbst eine MMU 165 beinhalten. Um Kommunikationen mit Plattform 110 zu ermöglichen, kann eine Bridge 155 vorhanden sein, um Kommunikationen, die gemäß einem Protokoll für Kopplungsstruktur 140 auftreten, in ein Protokoll umzuwandeln, das mit demjenigen konform ist, das bei einer Ein-Chip-System-(system an a chip, SoC)-Struktur 170 verwendet wird, die wiederum IP-Block 160 mit einem Lokalspeicher 180 koppelt, der erneut bei einigen Ausführungsformen ein DRAM sein kann. Während diese bestimmte Implementierung in der Ausführungsform von 1 gezeigt ist, ist der Umfang der vorliegenden Erfindung in dieser Hinsicht nicht eingeschränkt.
Ausführungsformen können Reverse Proxy Execution (RPE) implementieren, die die Fähigkeit einer CPU verbessert, Zugriffe auf physischen Speicher außerhalb von Onboard-Systemspeichern (z. B. Hauptplatine) zu erkennen. Anschließend können Zugriffe auf solche Orte in eine Klasse an Zugriffen umgewandelt werden, die über die periphere Struktur zu dem Beschleuniger getunnelt sind. Der Beschleuniger wiederum bedient die Zugriffe von seinem physischen Lokalspeicher. Unter Verwendung von kombinierter RPE und Proxy Execution (bei der eine CPU bei der Ausführung eines Speicherzugriffs unter Anfrage eines Beschleunigers helfen kann), kann jeder Beschleuniger mit einer separaten MMU, die über eine (kohärente oder nicht-kohärente) Struktur mit einer Multi-Sockel-CPU gekoppelt ist, einen gemeinsam benutzten virtuellen Adressraum für physischen Speicher errichten, einschließlich sowohl Systemspeicher als auch Lokalspeicher auf einem Beschleuniger. Unter Verwendung von RPE und Proxy Execution kann eine Ausführungsform dem gleichen multithreaded gemeinsam benutzten virtuellen speicherbasierten Programm, das für traditionelles symmetrisches Multiprocessing (symmetric multiprocessing, SMP) errichtet wurde, ermöglichen, Threads über CPUs zu verteilen, die sich entweder über mehrere CPU-Sockel oder über mehrere Stops auf einer peripheren Eingangs-/Ausgangs-(I/O)-Struktur befinden.
Gemeinsam mit Architekturmechanismen können Ausführungsformen ebenfalls Firmware- und Systemsoftwareerweiterungen beinhalten, die Steuerung und Datentransfers zwischen Kernen auf den Sockeln und dem Beschleuniger (oder CPUs) über eine periphere Kopplungsstruktur ermöglichen, um transparent auf unterschiedlichen Abstraktionsebenen zu arbeiten, die zwischen vollständiger OS-Laie und OS-Profi rangieren, wobei es dafür jeweils unterschiedliche Möglichkeiten zur Optimierung gibt.
Daten können, basierend auf Zugriffsmustern auf die gemeinsam benutzten Daten von der CPU-Seite als auch der Beschleuniger-Seite, auf einer Bedarfsbasis gemeinsam benutzt werden. Beschleuniger, die mit virtuellen Adressen arbeiten können und Adressübersetzung unterstützen, können den gleichen Code transparent ausführen, wobei Referenzierungen der Daten und des Codes intakt bleiben, da die gleichen virtuellen Adressen verwendet werden können, wenn auf den Code oder Daten verwiesen wird, wenn der Beschleuniger einen Teil des Anwendungsprogramms ausführt. Die physische Seite, die den Code oder Daten beinhaltet, kann sich entweder lokal zum Beschleuniger befinden oder kann aus dem Systemspeicher abgerufen werden. Die virtuelle Seite kann von einem entfernten Ort zu einem lokalen Ort verschoben werden, basierend auf der Zugriffshäufigkeit, ohne einer ausdrücklichen Beteiligung des Anwendungssoftwarestapels, da die Anwendung keine Datenverschiebung verwalten muss, um auf dem Beschleuniger eine Berechnung aufzubauen.
Treibersoftware hat oftmals die Aufgabe, Daten ausdrücklich unter der Verwendung von Direktspeicherzugriff-(direct memory access, DMA)-Transfers zwischen dem Hauptsystemspeicher und Fernspeicher, der sich lokal zum Beschleuniger befindet, mengenweise zu verschieben. Im traditionellen Treibermodel verbleiben ein Anwendungsprogramm, das auf einer CPU läuft, und ein Treiberprogramm, das einen Beschleuniger verwaltet, typischerweise in zwei getrennten virtuellen Adressräumen. Infolgedessen kommt es zu deutlichem Aufwand bei Datenkommunikationen zwischen der Anwendung und dem Treiber und dem Datentransfer zwischen dem Systemspeicher und Lokalspeicher auf dem Beschleuniger. Weiter wird dieser Datentransfer typischerweise von einem Anwendungscode implementiert, der von dem Programmierer geschrieben ist. Beispielsweise kann es erforderlich sein, dass ein Programmierer einen händlerspezifischen Satz an Application Programming Interfaces (APIs) benutzen muss, um Daten manuell vom Systemspeicher in den Beschleunigerspeicher zu verschieben. Stattdessen vereinfacht die Erzeugung eines gemeinsam benutzten virtuellen Adressraums zwischen der CPU und Beschleunigerkernen in Übereinstimmung mit einer Ausführungsform der vorliegenden Erfindung das gemeinsame Benutzen von Daten erheblich, ohne der ausdrücklichen Verwaltung von DMA-Operationen, da der vollständige Anwendungscode und Daten in einem herkömmlichen gemeinsam benutzten virtuellen Adressraum platziert werden können, ohne dass die Daten ausdrücklich durch Ändern des Anwendungsprogramms, z. B. mit einer vom Programmierer ausdrücklichen Orchestration von DMA-Operationen, verschoben werden müssen. Daher sind Datentransfers, obwohl sie weiterhin von DMA sein können, nicht vom Programmierer gesteuert. Mit anderen Worten kann ein Prozessor während der Ausführung einer User Level-Anwendung direkt auf Daten zugreifen, die in einem Fernspeicher vorhanden sind, ohne ausdrückliche Programmierung des Programmierers, die zugrundeliegenden Strukturen zu konfigurieren und zu verwalten, um den Datenzugriff zu ermöglichen.
Um einen gemeinsam benutzten Adressraum zwischen der CPU und dem Beschleuniger zu konstruieren, kann eine Speichermanagementeinheit veranlassen, dass Lade-/Speicherzugriffe auf den gemeinsam benutzten virtuellen Adressraum an den Fernspeicher gesendet werden, basierend auf den Inhalten der Seitentabellen, die verwendet werden, um virtuelle Adressen in physische zu übersetzen.
Systemsoftwareunterstützung kann einem Laufzeitsystem ermöglichen, transparent und dynamisch den Ort einer virtuellen Seite zu verschieben, sodass ein herkömmlicher gemeinsam benutzter virtueller Adressraum zwischen CPU und Beschleuniger erzeugt werden kann, und das Laufzeit-Arbeitssatz-Lokalitätsverhalten des Programms wird eingesetzt, um die virtuelle Seite entweder entfernt zu lokalisieren, wenn die Zugriffe selten stattfinden, oder diese lokal für Seiten zu lokalisieren, auf die häufig zugegriffen wird.
Bei verschiedenen Ausführungsformen können unterschiedliche Mechanismen zur Erweiterung virtueller Speicherunterstützung bereitgestellt werden. Eine Implementierung beinhaltet keine OS-Änderung an dem bestehenden Legacy-Funkrufsystem, während andere Implementierungen den Seitentabelleneinträgen mehr Informationen hinzufügen können. Diese Mechanismen involvieren ähnliche Architekturmechanismen, um Reverse Proxy Execution zu unterstützen, d. h. die Fähigkeit der CPU diese virtuellen Adresszugriffe, die nicht dem Systemspeicher zugeordnet sind, sondern dem physischen Fernspeicher, der sich lokal zu den Beschleunigern befindet, über eine periphere Struktur zu identifizieren und zu bedienen.
Um RPE zu unterstützen, kann eine CPU identifizieren, ob eine gegebene virtuelle Adresse einem Systemspeicher oder einem Fernspeicher über eine periphere Struktur zugeordnet ist. Wenn die physische Adresse einem Systemspeicher zugeordnet ist, kann der Zugriff lokal mit einem normalen Speicherzugriff verarbeitet werden, ansonsten kann RPE angewiesen werden, den Zugriff zu verarbeiten. Bei einer Ausführungsform kann die RPE unter Verwendung eines zugeordneten Mikrocode-Flusses umgesetzt werden. RPE kann beginnen, indem der Zugriff (z. B. Laden/Speichern (load/store, LD/ST) mit einer speziellen Störungsbedingung, die von einem Mikrocode-Verarbeiter verarbeitet wird, gekennzeichnet wird. Der Verarbeiter kann den Zugriff in LESE-/SCHREIB-/DMA-Transaktionen über die periphere Struktur umwandeln, obwohl mehrere Variationen möglich sind. Zur Vereinfachung der Beschreibung wird angenommen, dass die periphere Struktur eine PCIe^TM-Kopplungsstruktur ist, und jeder einzelne Zugriff auf den physischen Fernspeicher wird in einen nicht-cachespeicherbaren Zugriff und wiederum in PCIe^TM-Datentransaktionen umgewandelt, um die Anfrage/Daten über die PCIe^TM-Struktur zu tunneln. Die Transaktion kann entweder die ursprüngliche virtuelle Adresse oder die physische Adresse beinhalten. Der CPU-Thread, der den Zugriff ausführt, kann bei einigen Ausführungsformen die ausstehende Ausführung des entfernten Zugriffs blockieren (und kann zu einem anderen Thread schalten). Wenn der Beschleuniger die Benachrichtigung der PCIe^TM-Transaktion einer Zugriffsanfrage von der CPU erhält, verarbeitet die Ablaufsteuerung in dem Beschleuniger die Anfrage als ein spezielles Unterbrechungsereignis. Die Ablaufsteuerung extrahiert die Zugriffsadresse und Zugriffsart von der Anfrage. Wenn die Zugriffsadresse eine virtuelle Adresse ist, kann die Ablaufsteuerung die Übersetzung lokal über eine lokale MMU ausführen, um die physische Adresse zu erhalten. Unter Verwendung der physischen Adresse beginnt die Beschleuniger-Ablaufsteuerung entweder mit dem Speichern (bei einer Schreibtransaktion) oder erhält Daten für das Laden (bei einer Lesetransaktion). Die Ablaufsteuerung erstellt eine Antwort (z. B. im Fall eines Ladens) in einer PCIe^TM-Transaktion und sendet diese an den Host-Root (d. h. die CPU) zurück. Der CPU-Kern empfängt die PCIe^TM-Transaktion und den Status des ausgeführten Zugriffs und nimmt die nachfolgende Operationauf, was einen Zugriffsfehler, basierend auf dem Zugriffsstatus des entfernten Zugriffs, aufwerfen kann.
Es wird Bezug genommen auf 2, die ein Ablaufdiagramm für Reverse Proxy Execution gemäß einer Ausführungsform der vorliegenden Erfindung zeigt. Wie in 2 gezeigt, kann Verfahren 200 verwendet werden, um auf Daten zuzugreifen, die in einem Lokalspeicher eines Beschleunigers vorhanden sind, d. h. ein Fernspeicher hinsichtlich einer CPU. Wie in 2 gezeigt, kann Verfahren 200 mit dem Erhalten einer Speicherzugriffsanfrage (Block 210) beginnen. Diese Anfrage kann in einer Host-CPU empfangen werden, die wiederum die Anfrage an eine MMU weiterleitet, z. B. ein TLB, um zu bestimmen, ob der Eintrag für eine virtuelle Adresse ist, die in dem TLB (Raute 220) vorhanden ist. Wenn nicht, kann ein Page Miss-Verarbeiter ausgeführt werden, um den Eintrag zu erhalten und im TLB (Block 225) zu speichern.
Wenn der Eintrag im TLB vorhanden ist, kann er analysiert werden, um einen Ort der entsprechenden physischen Adresse (Block 230) zu bestimmen. Beispielsweise, wie nachstehend erörtert, kann jeder TLB-Eintrag Information beinhalten, um anzuzeigen, ob die entsprechende Seite in Lokal- (d. h. Systemspeicher) oder Fernspeicher vorhanden ist. Wenn die physische Adresse in Systemspeicher (Raute 240) vorhanden ist, geht die Steuerung weiter zu Block 245, wo eine Speicherzugriffsanfrage an den Systemspeicher ausgeführt wird, und dementsprechend können die angefragten Daten als eine Antwort an den Anfrager (Block 250) bereitgestellt werden.
Wenn stattdessen bei Raute 240 bestimmt wird, dass sich die physische Adresse nicht im Systemspeicher befindet, geht die Steuerung stattdessen weiter zu Block 260. Bei Block 260 kann eine Reverse Proxy Execution-Anfrage erzeugt werden, um die Speicherzugriffsanfrage an den Fernspeicher (z. B. ein Lokalspeicher eines Beschleunigers), der die Daten enthält, zu senden. Bei verschiedenen Implementierungen kann diese Anfrage über eine nicht-kohärente Kopplungsstruktur, z. B. als eine spezialisierte Lade-/Speicheranfrage, getunnelt werden. Nachdem diese Reverse Proxy Execution-Anfrage auf dem Beschleuniger verarbeitet wurde, geht die Steuerung weiter zu Block 270, wo das Ergebnis der Reverse Proxy Execution-Anfrage empfangen wird, nämlich die angefragten Daten werden empfangen und dem Anfrager kann eine Antwort bereitgestellt werden, wie vorstehend mit Bezug auf Block 250 erörtert. Während diese bestimmte Implementierung in der Ausführungsform von 2 gezeigt ist, ist der Umfang der vorliegenden Erfindung in dieser Hinsicht nicht eingeschränkt.
Es wird Bezug genommen auf 3, die ein Blockdiagramm zeigt, das Operationen für Reverse Proxy Execution gemäß einer erfindungsgemäßen Ausführungsform zeigt. Wie in 3 gezeigt, wenn eine Anfrage für einen Zugriff (1) auf eine virtuelle Adresse (V.A)X von CPU 120 an MMU 125 fehlschlägt (z. B. der Lookup zeigt an, dass die Seite in dem Lokalspeicher der Beschleunigerkarte vorhanden ist), wird eine Reverse Proxy Execution-Anfrage vorbereitet und an Beschleunigerkarte 150 gesendet (2). Der Beschleuniger 160 wiederum verarbeitet die Anfrage, um die Speicherzugriffsanfrage (3) an MMU 165 zu senden, die wiederum auf die angefragte Seite in Lokalspeicher 180 zugreift (4), sodass die angefragten Daten an CPU 120 zurückgesendet werden können (5). Es ist anzumerken, dass die Daten vom Beschleuniger an die Host-CPU über DMA gesendet werden können, oder alle unter dem Host innerhalb seiner glorifizierten LD/ST-Implementierung (z. B. Mikrocode-Fluss) abgerufen werden. Mit anderen Worten, sobald die CPU einen Zugriff auf einen Fernspeicher sendet, schaltet die CPU den Zugriff auf eine Mikrocode-Routine, um ein glorifiziertes LD/ST durchzuführen, die entweder auf eine DMA-Unterbrechung wartet oder ein aktives Abfragen ausführt, um die „Rücklauf”-Daten vom Beschleuniger zu erhalten. Das Ausführen des Speicherzugriffs auf (V.A)X wird auf eine Art und Weise ausgeführt, die dem Anwendungsprogramm, das auf den Speicherort, der bei virtueller Adresse X identifiziert wurde, zugegriffen hat, gegenüber transparent ist.
Im Großen und Ganzen agiert die RPE-Operation wie eine Speicherzugriffsoperation mit langer Latenz über ein nicht-uniformes Speicherarchitektur-(non-uniform memory architecture, NUMA)-System. Der zugrundeliegende Tunnelmechanismus kann variieren, abhängig von der Beschaffenheit der Struktur. Im Falle einer PCIe^TM-Struktur, aufgrund der Asymmetrie zwischen Root (System) und Nachfolger (Beschleuniger) Komplex, wo der Beschleuniger auf einen Bereich von Systemspeicher zugreifen kann, obwohl die CPU normalerweise nicht auf einen Lokalspeicher des Beschleunigers zugreifen kann, können verschiedene Optimierungen der RPE-Leistungsmechanismen unter Verwendung eines Teils des Systemspeichers oder des Lokalspeichers des Beschleunigers als Privatspeicher umgesetzt werden. Bei einer Ausführungsform kann ein Teil des Systemspeichers als Cache für den entfernten Lokalspeicher des Beschleunigers reserviert werden. Oder eine Privatspeicherregion kann zugeteilt werden, um als Puffer zu agieren, um die virtuellen Seiten zu halten, auf die von der Ferne aus zugegriffen wird. Denn z. B. der Zugriff auf eine virtuelle Adresse X, die einer entfernten Seite zugeordnet ist, kann darin resultieren, dass die gesamte Seite vorübergehend in den lokalen Puffer eingelesen wird, wo sie für zukünftige Zugriffe verfügbar ist, um Zugriffe auf Fernspeicher zu verringern.
Bei einer Ausführungsform kann ein Proxy Execution-Mechanismus verwendet werden, um eine Seitenstörungs-Situation zu verarbeiten, die bei der Beschleuniger-Ablaufsteuerung aufgetreten ist, was bedeutet, dass der Fehler an die CPU zur Verarbeitung gesendet werden kann. Dies bedeutet, dass die MMU bei der Beschleuniger-Ablaufsteuerung mit der MMU der CPU kohärent ist, und dass alle auf die gleiche Seitentabelle des OS verweisen. Eine Seitenstörung einer virtuellen Seite, entweder verursacht durch Operation auf der CPU oder dem Beschleuniger, bringt die CPU dazu, einen traditionellen Seitenverarbeitungsmechanismus zu verwenden, um die Seite in den Speicher zu überführen. Wenn der Fehler von einem Zugriff auf der Beschleuniger-Ablaufsteuerung verursacht wurde, kann die CPU die neue Seite in dem entfernten physischen Lokalspeicher des Beschleunigers anlegen. Ansonsten kann die Seite im Systemspeicher platziert werden. Ein Non Faulting-Zugriff auf der CPU auf eine virtuelle Adresse, die einem entfernten Lokalspeicher des Beschleunigers zugeordnet ist, stellt sicher, dass zu einer physischen Seite auf dem Beschleuniger zugeordnet wird, wodurch sichergestellt wird, dass die Proxy Execution ausgeführt wird.
Es wird Bezug genommen auf 4, die ein Ablaufdiagramm eines Verfahrens für Proxy Execution gemäß einer erfindungsgemäßen Ausführungsform zeigt. Wie in 4 gezeigt, kann Verfahren 300 verwendet werden, um Proxy Execution durchzuführen, wenn Daten, die von einem Beschleuniger gewünscht werden, nicht in seinem Lokalspeicher vorhanden sind.
Wie in 4 gezeigt, kann Verfahren 300 beginnen, indem eine Speicherzugriffsanfrage von einem Beschleuniger (Block 310) erhalten wird. Es kann sodann bestimmt werden, ob ein Eintrag für eine virtuelle Adresse der Anfrage in einem TLB des Beschleunigers (Raute 350) vorhanden ist. Wenn ja, kann unter Verwendung dieser virtuellen Adresse (Block 370) auf den Lokalspeicher des Beschleunigers zugegriffen werden und eine Antwort an den Anfrager (Block 380) bereitgestellt werden.
Wenn andererseits kein Eintrag in dem TLB vorhanden ist, geht die Steuerung weiter zu Block 330, wo eine Proxy Execution-Anfrage an die CPU (Block 330) gesendet werden kann. Wenn angenommen wird, dass die angefragte Übersetzung nicht in der MMU der CPU vorhanden ist, dann kann ein Page Miss-Verarbeiter gestartet werden, um den Eintrag (Block 335) zu erhalten. Des Weiteren kann die Seite, die dieser virtuellen Seite entspricht, aus dem Systemspeicher in den Lokalspeicher des Beschleunigers (Block 340) verschoben werden. Sodann kann eine Wiederaufnahme-Nachricht von der CPU an den Beschleuniger (Block 350) gesendet werden. Dementsprechend kann der Beschleuniger die Speicheranfrage an seinen TLB (Block 360) wiederholen. Da der Eintrag nun in der MMU vorhanden ist, kann eine Speicherzugriffsanfrage an den Lokalspeicher ausgeführt werden, um die angefragten Daten (Block 370) zu erhalten. Dementsprechend kann eine Antwort, die die angefragten Daten enthält, dem Anfrager (Block 380) bereitgestellt werden.
Es wird Bezug genommen auf 5, die ein Blockdiagramm zeigt, das Proxy Execution-Operationen gemäß einer Ausführungsform der vorliegenden Erfindung veranschaulicht. Wie in 5 gezeigt, kann Proxy Execution auftreten, wenn ein Beschleuniger Zugriff (1) auf eine virtuelle Adresse (V.A)X anfragt, die nicht in lokaler MMU 165 vorhanden ist. Dementsprechend wird eine Proxy Execution-Anfrage (2) über diese Seitenstörung an die CPU 120 gesendet. 5 zeigt eine Implementierung, bei der MMU 165 die Proxy Execution-Anfrage direkt an die CPU 120 sendet. Wenn jedoch Proxy in Page Walking-Code (Mikrocode, Firmware oder Software, abhängig davon, wie die MMU verwaltet wird) implementiert ist, dann kann dieser Code die Proxy-Anfrage senden. CPU 120 sendet die Anfrage (3) an lokale MMU 125, die wiederum für die angefragte virtuelle Adresse auf die Seite in Systemspeicher 130 zugreift (4). Wie gezeigt, wenn die Anfrage ein Lesen von Daten anfragt, dann kann die gesamte Seite von Systemspeicher 130 an Lokalspeicher 180 gesendet werden (5). Bei einer Ausführungsform kann der Datentransfer über CPU 120 erfolgen, die DMA programmiert, um Daten von einer Region in Systemspeicher 130 in eine Region in Lokalspeicher 180 zu kopieren. Alternativ kann CPU 120 die Kopie ausführen, indem einzelne „glorifizierte” Lade-/Speicherbefehlssequenzen, z. B. unter Verwendung von Mikrocode implementiert, wie vorstehend beschrieben, ausgeführt werden. Anschließend kann CPU 120 eine Wiederaufnahme-Nachricht (6) an Beschleuniger 160 senden, der wiederum den Zugriff (7) auf MMU 165 erneut versucht, die nun die Übersetzung vorliegend findet und die Anfrage (8) sendet, um die entsprechenden Daten von Lokalspeicher 180 zu erhalten. Es ist anzumerken, dass, um Zugriff auf die Daten in Lokalspeicher 180 zu ermöglichen, die MMU 165 adressierbar gemacht wird. CPU 120 kann direkt ein einzelnes „glorifiziertes” LD/ST ausführen, um den Übersetzungseintrag von der Seitentabelle in dem Systemspeicher 130 in MMU 165 zu aktualisieren. Alternativ kann CPU 120 die Seitentabelle oder einen Teilsatz der Seitentabelle, die die Übersetzung enthält, in die Beschleunigerseite über einen Datentransfer zu Lokalspeicher 180 kopieren und sodann den Beschleuniger 160 wiederaufnehmen, dessen Page Walker die Seitentabelle, die nun lokal ist, durchgeht.
Die Information zur Unterscheidung, ob eine virtuelle Adresse auf der CPU lokal (im Systemspeicher) oder entfernt (in dem Beschleunigerspeicher) ist, kann vom OS kommen, das diese Information von dem Basis-Ein-/Ausgabe-System (basic input/output system, BIOS) erhält, das über eine Konfiguration des Systemspeichers vollständig in Kenntnis ist. Zur Unterstützung von RPE kann BIOS eine empfohlene Speichergröße auf dem Beschleuniger spezifizieren. Diese Operation ähnelt einer Festspeicher-(read only memory, ROM)/Arbeitsspeicher-(random access memory, RAM)-Bausteinauswahl, die von dem BIOS beim Starten ausgeführt wird. Das BIOS kann sodann die Summe von Systemspeicher und dem lokalen Beschleunigerspeicher melden und das OS darüber informieren, welcher Speicherbereich lokaler Systemspeicher und welcher entfernt ist.
Bei verschiedenen Ausführungsformen kann ein Zustand der Systemebene für BIOS, nämlich ein Satz an Deskriptor-Architekturzuständen, genannt Speicherpartitions-Deskriptoren, diesen Bereich an Information aufzeichnen, z. B. zumindest den Bereich an Information für den Systemspeicher, daher würde jede physische Adresse außerhalb dieses Bereichs als entfernt identifiziert werden. Bei einer Ausführungsform kann diese Information in einer in dem BIOS eingebauten Datenstruktur gespeichert werden. Die Speicherdeskriptoren können ebenfalls als Privatzustand in maschinenspezifischen Registern gespeichert werden, die sowohl von Software als auch von Mikrocode genutzt werden können. Es ist anzumerken, dass solche Bereichsinformation zuerst von BIOS erstellt wird, bevor das OS startet, sodass die Verwendung dieser Zustände nicht OS-abhängig ist. Mit anderen Worten kann der RPE-Mechanismus mit einem Legacy-OS arbeiten, dem die Unterscheidung zwischen Fern- und Lokalspeicher nicht einmal bekannt ist.
Für jegliches LD/ST, das von der CPU verarbeitet wird, kann es beschwerlich sein, dass jede TLB-Übersetzung ebenfalls die physische Adresse mit einem Speicherpartitions-Deskriptor vergleicht, um zu entscheiden, ob ein Zugriff auf lokalen oder entfernten Systemspeicher vorliegt. Stattdessen kann solch eine Überprüfung weg von dem kritischen Pfad in der MMU stattfinden und kann nur bei einem Durchgehen einer Seite beim Ausfüllen eines neuen TLB-Eintrags stattfinden. Bei einigen Ausführungsformen kann jeder TLB-Eintrag ein Attribut-Bit enthalten, um anzuzeigen, ob sich der entsprechende Eintrag im entfernten oder lokalen Systemspeicher befindet. Wenn ein neuer TLB-Eintrag angelegt wird, kann der Page Walker eine Bereichsüberprüfung des physischen Adressbereichs im Seitentabelleneintrag mit dem Speicherpartitions-Deskriptor ausführen. Es ist anzumerken, dass dieser Mechanismus selbst dann funktioniert, wenn das OS nicht unterscheidet, ob eine Seite lokal oder entfernt zugeordnet ist.
Bei einigen Ausführungsformen kann das OS die Richtlinie der Verwendung des Lokalspeicher des Beschleunigers verarbeiten, indem der Lokalspeicher des Beschleunigers verwendet wird, um nur den Teilsatz eines Anwendungscodes und Daten zu halten, auf die der Beschleuniger häufig zugreift. Wenn das OS in Unkenntnis ist, hilft ein Lokalitätsprinzip, z. B. einer Laufzeitschicht oder anderer Einheit, den Arbeitssatz dorthin zu verschieben, wo der Zugriff häufiger geschieht, im Systemspeicher oder Lokalspeicher eines Beschleunigers.
Zusätzlich kann, wie vorstehend beschrieben, das OS-Seitentabellenformat ein Attribut-Bit beinhalten, um anzuzeigen, ob die entsprechende Seite im Lokal- oder Fernspeicher gespeichert ist. Dieses Bit kann markiert werden, wenn das OS die Zuordnung der virtuellen Adresse zu der physischen Adresse festlegt, und das OS kann jede physische Seite mit dem Speicherpartitions-Deskriptor überprüfen, um die Seite als lokal oder entfernt zu markieren. Auf diese Art und Weise muss keine Bereichsüberprüfung eines jeden angelegten TLB-Eintrags ausgeführt werden. Um es Anwendungen zu ermöglichen, auf Speicher auf dem Beschleuniger zuzugreifen, kann die CPU Attribut-Bits analysieren, sodass sie ein Laden/Speichern in eine gegebene virtuelle Adresse an einen entfernten physischen Speicherort weiterleiten kann. Außerdem können die Attribut-Bits ebenfalls die Anzahl an Zugriffen zurückverfolgen, die entfernt ausgeführt werden, wodurch es der OS-Software ermöglicht wird, eine Richtlinie, basierend auf der Anzahl der entfernten Zugriffe, zu implementieren, sodass die Seite an einen anderen Ort verschoben werden kann, wenn die Anzahl an entfernten Zugriffen einen bestimmten Grenzwert übersteigt.
Obwohl es möglich ist, Fernspeicherzugriff zu implementieren, indem Schutzeinrichtungen einer virtuellen Seite, wie z. B. Markieren einer Seite als nicht zugreifbar oder nicht vorhanden und Verarbeiten sich ergebender Fehler, durchgesetzt werden, steigt die Zugriffslatenz, da der Seitenstörungsverarbeiter jedes Mal laufen muss, wenn ein Speicherzugriff stattfindet. Stattdessen kann unter Verwendung einer erfindungsgemäßen Ausführungsform eine CPU eine Ortsadresse des Fernspeichers an einen Bus-Controller übergeben, der den Zugriff auf den Speicherort des Beschleunigers leitet. Beispielsweise kann die CPU direkt Lade-/Speichervorgänge umleiten, indem auf einen Standardsatz an Registern zugegriffen wird, die in dem Bus-Controller definiert sind, um auf den Fernspeicherort zuzugreifen, ohne der Hilfe von Software bei der Ausführung des Laden/Speicherns. Dieser Datentransfer kann durch DMA (Mengentransfer) sein oder ein skalarer Transfer bei Cacheline-Granularität. Die Fähigkeit, eine virtuelle Seite von einem Fernspeicherort an einen Lokalspeicherort (und umgekehrt) transparent zu verschieben, ermöglicht es Software (z. B. einer Anwendung), Daten mit den Beschleunigern gemeinsam zu benutzten, ohne eine Verschiebung der Daten ausdrücklich zu verwalten. Wenn der Beschleuniger nicht mit dem System verbunden ist oder in einen unempfänglichen Zustand übergeht, erzeugt die Adressübersetzungseinheit Seitenstörung, die den Grund für das Fehlschlagen des Laden/Speicherns anzeigen.
Es wird Bezug genommen auf 6, die einen beispielhaften Eintrag 400 in einer Seitentabelle in Übereinstimmung mit einer einer Ausführungsform der vorliegenden Erfindung zeigt. Wie gezeigt, kann jeder Eintrag ein Seitenbasisadress-(page base address, PBA)-Feld 410 beinhalten, das eine PBA speichert, die auf eine erste Adresse einer Seite, die in dem Speicher gespeichert ist, verweist. Zusätzlich kann jeder Eintrag ein Beschleunigerfeld 420 beinhalten, das einen n-Bit Beschleuniger-Identifikator (accelerator identifier, ID) speichert, um auf einen Beschleuniger zu verweisen, der sich in dem System befindet, das die Seite beinhaltet, ein Lokal-/Fernfeld 430, um zu speichern, z. B. einen n-Bit Identifikator, ob die entsprechende virtuelle Seite in Lokalspeicher oder in einem von möglicherweise vielen Fernspeichern gespeichert ist, ein Zählerfeld 440, um einen m-Bit Zähler zu speichern, der die Anzahl an Zugriffen zählt, die auf den Fernspeicher erfolgen (sodass der Zähler nur dann aktiv ist, wenn sich die Seite im Fernspeicher befindet), und ein Attributfeld 450, um verschiedene Bits zu speichern, um unterschiedliche Attribute der Seite anzuzeigen.
Bei einer Ausführungsform erfolgt eine Ausnahme, wenn der Wert des Zugriffszählers Null erreicht. Diese Ausnahme ermöglicht der OS-Software, z. B. einem virtuellen Speichermanagement-Kernel, der für Seitenmigration verantwortlich ist, Migrationsrichtlinien, basierend auf der Anzahl der Zugriffe auf die gegebene virtuelle Seite, zu verwalten. Das heißt, die Software kann den virtuellen Adressraum verwalten, in dem die Anwendung läuft, sodass der virtuelle Adressraum physische Speicherseiten, die sich näher zur CPU oder näher zum Beschleuniger befinden, zuordnen kann. Bei Beschleunigern, die mit einem PCIe^TM-Bus gekoppelt sind, kann die zugrundeliegende Laufzeitsoftware den softwarebasierten Kohärenzmechanismus implementieren, da der Bus nicht-kohärent ist. Bei einem umkämpften Zugriff auf jegliche gemeinsam benutzte Datenstruktur kann eine Synchronisationssteuerung, wie ein Semaphor, verwendet werden, sodass der Erzeuger-Thread den Semaphor solange nicht freigibt, bis er bereit ist, die Daten an den Verbraucher zu übergeben. Bevor der Erzeuger den Semaphor freigibt, muss er alle ungesicherten Cache-Lines, die die gemeinsam benutzten Daten betreffen, in den Speicher flushen. Dadurch wird sichergestellt, dass, wenn der Verbraucher-Thread auf dem Beschleuniger den Zugriff auf die gemeinsam benutzten Daten von dem Speicher startet, die Daten kohärent sind, sogar wenn die Struktur zwischen dem Host-CPU und dem Beschleuniger Cache-Kohärenz nicht unterstützt. Umgekehrt, wenn der Beschleuniger die Verarbeitung der gemeinsam benutzten Daten ausführt, können ähnliche Synchronisations- und Flush-Mechanismen verwendet werden, um speicherbasierte Daten-Kohärenz sicherzustellen. Sollte die Struktur zwischen der CPU und dem Beschleuniger cachekohärent sein (z. B. eine Zukunftsgeneration von PCIe), ist es nicht erforderlich, bei einer Übergabe ungesicherte Lines in den Speicher zu flushen, bevor der Erzeuger den Semaphor freigibt.
Bei Ausführungsformen mit OS-Unterstützung kann die Zuteilung und Verwaltung von Speicher auf dem Beschleuniger zusammen mit dem Speichermanager des OS erledigt werden, der die Systemspeicherseiten, die der Anwendung zugewiesen werden, zuteilt und verwaltet, und der die Seitentabellen verwaltet, die von der CPU eingesetzt werden, um virtuelle Adressen in physische Adressen zu übersetzen. Der Speichermanager verarbeitet ebenfalls Ausnahmen, die aufgrund der Umleitung des Zugriffs auf Fernspeicher auftreten, und verwaltet die Richtlinie hinter der Migration der physischen Seiten zwischen der CPU und dem Beschleuniger. Die Richtlinie der Seitenmigration kann variieren, abhängig von dem Verhalten der Arbeitslast, und kann potentiell verändert werden, um die Anzahl an Fernzugriffen zu verringern (bevor die entsprechende Seite in den Systemspeicher verschoben wird), oder eine erste Tastrichtlinie implementieren, um die Seite an den Ort zu verschieben, an dem es eine maximale Anzahl an Zugriffen gibt. Code und schreibgeschützte Datenseiten können in mehreren Speichern dupliziert werden, um unnötiges Hin- und Herverschieben der physischen Seiten zu verhindern. Nur die Datenseiten, die Daten enthalten, die während der Programmausführung verarbeitet werden, werden hin- und herverschoben, basierend auf der Lokalität des Zugriffs auf Datenseiten.
Es wird Bezug genommen auf 7, die ein Blockdiagramm eines Prozessors in Übereinstimmung mit einer Ausführungsform der vorliegenden Erfindung zeigt. Wie in 7 gezeigt, kann Prozessor 500 ein mehrstufiger Out-Of-Order-Prozessor mit Pipeline sein. Prozessor 500 wird in 7 verhältnismäßig vereinfacht gezeigt, um verschiedene Merkmale zu veranschaulichen, die in Verbindung mit Proxy Execution und Reverse Proxy Execution in Übereinstimmung mit einer Ausführungsform der vorliegenden Erfindung verwendet werden.
Wie in 7 gezeigt, umfasst Prozessor 500 Front-End-Einheiten 510, die zum Einholen von auszuführenden Makrobefehlen und zu deren Vorbereitung für die spätere Verwendung im Prozessor genutzt werden können. Beispielsweise können Front-End-Einheiten 510 eine Einholeinheit 504, einen Befehls-Cache 506 und einen Befehlsdecoder 508 beinhalten. Bei einigen Ausführungsformen können Front-End-Einheiten 510 weiter einen Trace-Cache beinhalten, zusammen mit Mikrocode-Speicher sowie einem Mikrooperations-Speicher. Einholeinheit 504 kann Makrobefehle, z. B. von Speicher oder Befehls-Cache 506, einholen und diese dem Befehlsdecoder 508 zuführen, um diese in die primitive Form zu entschlüsseln, d. h. Mikrooperationen für die Ausführung durch den Prozessor. Front-End-Einheiten 510 beinhalten weiter eine MMU 509 in Übereinstimmung mit einer Ausführungsform der vorliegenden Erfindung, um Einträge zu speichern, einschließlich zusätzlicher Zustandsinformation, um Proxy Execution und Reverse Proxy Execution, wie hierin beschrieben, zu verarbeiten. Basierend auf solchen Informationen, können Operationen in einem gemeinsam benutzten virtuellen Speicherraum, einschließlich einem Systemspeicher und Lokalspeicher eines oder mehr Beschleunigern, effizient ausgeführt werden, ohne Unterstützung bei der Verschiebung von Daten durch einen Programmierer.
Zwischen den Front-End-Einheiten 510 und den Ausführungseinheiten 520 ist eine OOO-(out of Order)-Engine 515 eingekoppelt, die zum Empfangen der Mikrobefehle und deren Vorbereitung für die Ausführung verwendet werden kann. Spezieller kann die OOO-Engine 515 verschiedene Puffer für die Rückordnung des Mikrobefehlsflusses und die Zuteilung verschiedener für die Ausführung benötigter Ressourcen umfassen, u. a. auch für die Bereitstellung der Umbenennung von logischen Registern in den Speicherorten innerhalb verschiedener Registerdateien, wie die Registerdatei 530 und die erweiterte Registerdatei 535. Registerdatei 530 kann separate Registerdateien für Integer- und Floating-Point-Operationen umfassen. Die erweiterte Registerdatei 535 kann als Speicher für Einheiten in Vektorgröße dienen, z. B. 256 oder 512 Bit pro Register.
Verschiedene Ressourcen können in Ausführungseinheiten 520 vorhanden sein, u. a. in verschiedenen Logik-Einheiten für Integer, Floating-Point und Single-Instruction-Multiple-Data (SIMD) sowie in anderer spezialisierter Hardware. Die Ergebnisse können einer Rückordnungslogik zugeführt werden, wie einem Rückordnungspuffer (reorder buffer, ROB) 540. Spezieller, umfasst ROB 540 verschiedene Arrays und Logik zum Empfangen der mit den ausgeführten Befehlen verbundenen Informationen. Diese Informationen werden dann von ROB 540 geprüft, um zu bestimmen, ob die Befehle richtig rückgeordnet und die resultierenden Daten in den Architektur-Zustand des Prozessors aufgenommen werden können, oder ob eine oder mehr Ausnahmen eingetreten sind, die eine richtige Rückordnung der Befehlen verhindern. Selbstverständlich kann ROB 540 andere Operationen, die mit Rückordnung verbunden sind, verarbeiten.
Wie in 7 gezeigt, ist ROB 540 mit einem Cache 550 gekoppelt, welcher bei einer Ausführungsform ein Low Level Cache sein kann (z. B. ein L1-Cache), der Umfang der vorliegenden Erfindung ist in dieser Hinsicht jedoch nicht eingeschränkt. Auch Ausführungseinheiten 520 können direkt mit dem Cache 550 gekoppelt sein. Von Cache 550 aus kann die Datenkommunikation mit Caches höherer Levels, Systemspeicher usw. erfolgen. Dieser High-Level ist bei der Ausführungsform von 7 gezeigt, wobei der Umfang der vorliegenden Erfindung in dieser Hinsicht nicht eingeschränkt ist.
Beispielsweise kann bei einigen Implementierungen ein Beschleuniger mit dem Prozessor auf dem Chip integriert sein. Bei einer Architektur beispielsweise ein Mehrkern-Prozessor, der eine Anzahl an einzelnen Prozessorkernen beinhaltet, zusammen mit Beschleunigern, die heterogene Kerne sein können, z. B. von einem Graphikprozessor, oder andere spezialisierte Verarbeitungseinheit. Im Allgemeinen kann Operation von Proxy Executions und Reverse Proxy Executions auf die gleiche Art und Weise stattfinden, wie vorstehend für auf dem Chip integrierten Beschleunigern beschrieben, die mit Kernen durch jede Art Kopplungsstruktur gekoppelt sein können, einschließlich kohärenter oder nicht-kohärenter Verbindungen.
Es wird Bezug genommen auf 8, die ein Blockdiagramm eines Systems in Übereinstimmung mit einer weiteren Ausführungsform der vorliegenden Erfindung zeigt. Wie in 8 gezeigt, beinhaltet System 600 einen Mehrkern-Prozessor 610, der auf einem einzelnen Halbleiter-Die gebildet sein kann und verschiedene Komponenten enthält. Speziell bei der Implementierung von 8, kann Prozessor 610 eine Vielzahl von Kernen 620a–620n beinhalten, von denen jeder einen TLB 625a–625n beinhalten kann, der Einträge beinhalten kann, die Übersetzungen und zusätzliche Felder, wie vorstehend erörtert, umfassen. Die Kerne wiederum können mit einem gemeinsam benutzten Cache 640 gekoppelt sein, der ein gemeinsam benutzter Last Level Cache sein kann, derart, dass jeder der einzelnen Kerne seinen eigenen Cache beinhalten kann. Wie weiter gezeigt, kann Prozessor 610 ebenfalls Beschleuniger beinhalten. Bei der gezeigten Ausführungsform sind zwei solche Beschleuniger gezeigt, obwohl der Umfang der vorliegenden Erfindung in dieser Hinsicht nicht eingeschränkt ist. Die Verbindung der Beschleuniger mit den Kernen kann durch jede Art Kopplungsstruktur sein, wie z. B. eine kohärente oder nicht-kohärente Verbindung, z. B. eine PCIe^TM-Verbindung, eine Kopplungsstruktur mit gemeinsam benutztem Bus und so weiter. Beschleuniger 630a und 630b sind gezeigt und beinhalten jeweils TLBs 635 mit Einträgen, wie vorstehend beschrieben. Außerdem kann Prozessor 610 einen Speicher-Controller 650 beinhalten.
Bei einer Implementierung kann Prozessor 610 mit einem Speicher 660 gekoppelt sein, der ein Systemspeicher sein kann, der in mehrere Partitionen aufgeteilt werden kann, z. B. einschließlich einer ersten Partition 665a, die mit den Prozessorkernen verbunden sein kann, und einer zweiten Partition 665b, die mit den Beschleunigern verbunden sein kann. Selbstverständlich können Speicher, die mit den Kernen und Beschleunigern verbunden sind, unterschiedlich konfiguriert sein, z. B. über unterschiedliche Standardschnittstellen und als unterschiedliche Speichermodule und so weiter. Prozessor 610 kann weiter mit einem Chipsatz 670 gekoppelt sein, der wiederum mit verschiedenen Peripheriegeräten, wie z. B. Eingangs-/Ausgangsgeräten, Speichergeräten, anderen Beschleunigern und so weiter, gekoppelt sein kann.
Dementsprechend können Ausführungsformen eine Verarbeitung von Proxy Executions und Reverse Proxy Executions in verschiedenen Systemen bereitstellen, die integrierte Beschleuniger oder Beschleuniger, die über eine kohärent oder nicht-kohärente Verbindung gekoppelt sind, beinhalten.
Ausführungsformen können als Code implementiert und auf einem Speichermedium gespeichert werden, das Befehle enthält, die zum Programmieren eines Systems für die Ausführung der Befehle verwendet werden können. Das Speichermedium kann beinhalten, ist aber nicht beschränkt auf, jede Art Disks, u. a. Floppy Disks, Optische Disks, Solid State-Laufwerke (SSDs), Compact Disk Read-Only Memories (CD-ROMs), Compact Disk Rewritables (CD-RWs) und magnetooptische Disks (MO), Halbleiter-Geräte, wie Read-Only Memories (ROMS), Random Access Memories (RAMs), wie dynamische Random Access Memories (DRAMs), statische Random Access Memories (SRAMs), Erasable Programmable Read-Only Memories (EPROMs), Flash Memories, Electrically Erasable Programmable Read-Only Memories (EEPROMs), magnetische oder optische Karten oder jede andere Art Speichermedium, das sich für das Speichern von elektronischen Befehlen eignet.
Obwohl die vorliegende Erfindung im Hinblick auf eine begrenzte Anzahl an Ausführungsformen beschrieben wurde, sind sich Fachleute bewusst, dass viele weitere Modifikationen und Varianten davon möglich sind. Die beigefügten Ansprüche sollen alle solchen Modifikationen und Varianten abdecken, die dem Sinn und Umfang der vorliegenden Erfindung entsprechen.

Claims

Verfahren, umfassend: Empfangen einer Speicherzugriffsanfrage, die eine virtuelle Adresse enthält; Analysieren eines Eintrags, der der virtuellen Adresse, die in einem Translation Lookaside-Puffer (translation lookaside buffer, TLB) eines Prozessores gespeichert ist, entspricht, um zu bestimmen, ob eine physische Adresse (physical address, PA), die der virtuellen Adresse entspricht, in einem Lokalspeicher, der mit dem Prozessor verbunden ist, oder in einem Fernspeicher, der mit einem Beschleuniger verbunden ist, der mit dem Prozessor über eine nicht-kohärente Verbindung gekoppelt ist, vorhanden ist, wobei der Lokalspeicher und der Fernspeicher zusammen einen gemeinsam benutzten virtuellen Speicherraum bilden; und wenn die PA im Fernspeicher vorhanden ist, Senden einer Reverse Proxy Execution-Anfrage an den Fernspeicher, um die Speicherzugriffsanfrage auszuführen.
Verfahren nach Anspruch 1, weiter umfassend das Bestimmen, ob die PA sich in dem Lokalspeicher oder dem Fernspeicher befindet, basierend auf einem Ortsindikator des TLB-Eintrags.
Verfahren nach Anspruch 2, weiter umfassend das Bestimmen, welcher einer Vielzahl von Fernspeichern, die jeweils mit einem Beschleuniger verbunden sind, in dem sich die PA befindet, unter Verwendung eines Identifikatorfeldes des TLB-Eintrags, das dem Beschleuniger anzeigt, mit welchem Fernspeicher er verbunden ist.
Verfahren nach Anspruch 3, weiter umfassend das Analysieren eines Zählers des TLB-Eintrags, der eine Anzahl an Zugriffen auf die PA des Fernspeichers durch den Prozessor anzeigt.
Verfahren nach Anspruch 4, weiter umfassend das Verschieben von Information von der PA des Fernspeichers in den Lokalspeicher, wenn der Zähler einen Grenzwert erreicht, ohne dass eine Anwendung, die auf dem Prozessor ausgeführt wird, beteiligt ist.
Verfahren nach Anspruch 1, weiter umfassend das Einstellen einer Speicherkonfiguration eines Systems, einschließlich den Lokalspeicher und den Fernspeicher, um einen ersten physischen Adressbereich anzuzeigen, der mit dem Lokalspeicher verbunden ist, und einen zweiten physischen Adressbereich, der mit dem Fernspeicher verbunden ist.
Verfahren nach Anspruch 6, weiter umfassend das Zugreifen auf die Speicherkonfiguration beim Durchgehen einer Seite, um die Übersetzung für die Speicherzugriffsanfrage zu erhalten, und das Speichern eines Eintrags in dem TLB, der die Übersetzung enthält, und eines Ortsindikators, der einen ersten Wert enthält, um anzuzeigen, dass die PA sich im Lokalspeicher befindet, wenn die PA sich innerhalb des ersten physischen Adressbereichs befindet.
Vorrichtung, umfassend: einen Prozessor mit einem ersten Kern, der eine erste Speichermanagementeinheit (memory management unit, MMU) enthält, wobei die erste MMU eine Vielzahl von Einträgen umfasst, um Übersetzungen von virtuellen Adressen in physische Adressen zu speichern, wobei jeder Eintrag ein Ortsfeld beinhaltet, um einen ersten Indikator zu speichern, um anzuzeigen, ob ein Speicherort für den entsprechenden Eintrag in einem Lokalspeicher vorhanden ist, der mit dem Prozessor gekoppelt ist, oder in einem Fernspeicher vorhanden ist, der mit einem Beschleuniger gekoppelt ist, der mit dem Prozessor über eine nicht-kohärente Kopplungsstruktur gekoppelt ist, und ein Identifikatorfeld, um einen Identifikator eines Beschleunigers zu speichern, der mit dem Fernspeicher verbunden ist.
Vorrichtung nach Anspruch 8, wobei jeder Eintrag der ersten MMU weiter einen Zähler beinhaltet, um eine Zählung einer Anzahl an Zugriffen auf den Speicherort des Fernspeichers durch den Prozessor zu speichern.
Vorrichtung nach Anspruch 8, wobei der Lokalspeicher ein Systemspeicher ist und der Fernspeicher ein Lokalspeicher des Beschleunigers ist.
Vorrichtung nach Anspruch 10, wobei der Systemspeicher und der Fernspeicher einen einzelnen virtuellen Adressraum umfassen.
Vorrichtung nach Anspruch 8, wobei ein Eintrag der ersten MMU anzeigt, dass der Speicherort sich im Fernspeicher befindet, wobei der Prozessor eine Speicheranfrage an den Beschleuniger über ein Protokoll der nicht-kohärenten Kopplungsstruktur tunneln soll.
Vorrichtung nach Anspruch 8, wobei der Beschleuniger eine zweite MMU beinhaltet und auf eine Seitenstörung auf der zweiten MMU reagiert, wobei der Beschleuniger bei dem Prozessor anfragen soll, die Seitenstörung zu bereinigen.
Vorrichtung nach Anspruch 13, wobei der Prozessor den Lokalspeicher veranlassen soll, eine Speicherseite, die mit einer Adresse der Seitenstörung verbunden ist, in den Fernspeicher zu übermitteln, und eine Übersetzung für die Speicherseite veranlassen soll, die an den Beschleuniger zur Speicherung in der zweiten MMU gesendet werden soll.
Vorrichtung nach Anspruch 8, wobei der Prozessor einen Speicherort, der im Fernspeicher vorhanden ist, unter Verwendung von Information in einem Eintrag der ersten MMU direkt adressieren soll.
Vorrichtung nach Anspruch 8, wobei der Prozessor eine Reverse Proxy Execution-Anfrage an den Beschleuniger ausgeben soll, um auf Daten zuzugreifen, die im Fernspeicher des Beschleunigers gespeichert sind, unter Verwendung von Information in einem Eintrag der ersten MMU und ohne Verwendung einer User Level-Anwendung, die auf dem Prozessor ausgeführt wird.
System, umfassend: einen Prozessor mit einem ersten Kern, der eine erste Speichermanagementeinheit (memory management unit, MMU) enthält, wobei die erste MMU eine Vielzahl von Einträgen umfasst, um Übersetzungen von virtuellen Adressen in physische Adressen zu speichern, wobei jeder Eintrag ein Ortsfeld beinhaltet, um einen ersten Indikator zu speichern, um anzuzeigen, ob ein Speicherort für den entsprechenden Eintrag in einem Systemspeicher oder in einem zweiten Speicher, der mit einer Beschleunigerkomponente verbunden ist, vorhanden ist, und einen Zähler, um eine Zählung einer Anzahl an Zugriffen auf den Speicherort des zweiten Speichers durch den Prozessor zu speichern; die Beschleunigerkomponente, die mit dem Prozessor über eine Verbindung gekoppelt ist, wobei die Beschleunigerkomponente einen zweiten Prozessor umfasst, und eine zweite MMU; und den Systemspeicher, der mit dem Prozessor gekoppelt ist, wobei der Systemspeicher dynamischen Direktzugriffsspeicher (dynamic random access memory, DRAM) umfasst.
System nach Anspruch 17, wobei der Prozessor einen Speicherort, der im zweiten Speicher vorhanden ist, unter Verwendung von Information in einem Eintrag der ersten MMU direkt adressieren soll.
System nach Anspruch 17, wobei der Systemspeicher und der zweite Speicher einen einzelnen virtuellen Adressraum beinhalten.
System nach Anspruch 18, wobei der Prozessor Information vom Speicherort auf dem zweiten Speicher, in einen Speicherort auf dem Systemspeicher, der auf eine Unterbrechung reagiert, die auftritt, wenn der Zähler einen Grenzwert erreicht, verschieben soll, ohne dass eine Anwendung, die auf dem Prozessor ausgeführt wird, beteiligt ist.
System nach Anspruch 17, wobei der Prozessor und die Beschleunigerkomponente aus einem einzelnen Halbleiter-Die gebildet sind.
System nach Anspruch 21, wobei der zweite Speicher ein aufgeteilter Teil des Systemspeichers ist.
Vorrichtung, umfassend: einen Prozessor mit einem ersten Kern, der erste Logik beinhaltet, um eine Speicherzugriffsanfrage nach Daten an einen Beschleuniger zu senden, der mit dem ersten Kern gekoppelt ist, die transparent gegenüber einer User Level-Anwendung ist, die auf dem ersten Kern, der die Daten anfragt, ausgeführt wird, wenn ein Speicherort der Speicherzugriffsanfrage in einem Speicher vorhanden ist, der mit dem Beschleuniger verbunden ist, und um von dem Beschleuniger, der auf die Speicherzugriffsanfrage reagiert, die Daten zu erhalten, die in dem Speicherort gespeichert sind.
Vorrichtung nach Anspruch 23, wobei der erste Kern einen ersten Speicher, der eine Vielzahl von Einträgen beinhaltet, umfasst, um Übersetzungen einer virtuellen Adresse in eine physische Adresse zu speichern, wobei jeder Eintrag zumindest einen Indikator umfasst, um anzuzeigen, ob ein Speicherort für den entsprechenden Eintrag in einem ersten Speicher, der mit dem ersten Kern verbunden ist, oder in einem Speicher, der mit einem Beschleuniger, der mit dem Prozessor gekoppelt ist, vorhanden ist, und einen Identifikator des Beschleunigers, mit dem der Speicher verbunden ist.
Vorrichtung nach Anspruch 24, wobei jeder Eintrag des ersten Speichers weiter einen Zähler beinhaltet, um eine Zählung der Anzahl an Zugriffen durch den ersten Kern auf den Speicherort des Speichers, der mit dem Beschleuniger verbunden ist, zu speichern.
Vorrichtung nach Anspruch 25, wobei, wenn ein Wert des Zählers größer als ein Grenzwert ist, die Daten, die in dem Speicherort gespeichert sind, in einen zweiten Speicherort im ersten Speicher verschoben werden sollen.
Vorrichtung nach Anspruch 26, wobei das Übertragen der Speicherzugriffsanfrage und das Verschieben der Daten gegenüber der User Level-Anwendung, die die Daten angefragt hat, transparent sind.
Vorrichtung nach Anspruch 24, wobei, wenn ein Eintrag des ersten Speichers anzeigt, dass der Speicherort in dem Speicher ist, der mit dem Beschleuniger verbunden ist, der Prozessor die Speicherzugriffsanfrage an den Beschleuniger über ein Protokoll einer Kopplungsstruktur, die den Prozessor und den Beschleuniger koppelt, tunneln soll.
Vorrichtung nach Anspruch 23, wobei der Prozessor einen Mehrkern-Prozessor umfasst, der den ersten Kern und den Beschleuniger beinhaltet, wobei der Mehrkern-Prozessor auf einem einzelnen Halbleiter-Die gebildet ist.
Vorrichtung nach Anspruch 23, wobei der erste Speicher und der Speicher, der mit dem Beschleuniger verbunden ist, einen einzelnen virtuellen Adressraum umfassen.