DE112020004181T5

DE112020004181T5 - Bereitstellen eines direkten datenzugriffs zwischen beschleunigern und speicher in einer datenverarbeitungsumgebung

Info

Publication number: DE112020004181T5
Application number: DE112020004181.6T
Authority: DE
Inventors: Zaid QURESHI; I-Hsin Chung; Wen-mei Hwu; JinJun Xiong
Original assignee: International Business Machines Corp
Current assignee: Ill Us, University of, Trustees of; International Business Machines Corp
Priority date: 2019-10-17
Filing date: 2020-10-13
Publication date: 2022-06-23
Also published as: JP2022552393A; WO2021074779A1; GB2604785A; JP7539202B2; CN115413338A; US11048447B2; US20210117333A1; GB2604785B

Abstract

Ein Verfahren zum Bereitstellen eines direkten Zugriffs auf einen nichtflüchtigen Speicher in einer Datenverarbeitungsumgebung durch einen Prozessor weist ein Bereitstellen eines direkten Zugriffs auf einen nichtflüchtigen Speicher für einen oder mehrere Beschleuniger über eine Schnittstelle zur Anwendungsprogrammierung („API“), unabhängig von einer zentralen Host-Verarbeitungseinheit („CPU“) auf einem Steuerpfad oder Datenpfad, auf, um einen Arbeitsschritt des Lesens und einen Arbeitsschritt des Schreibens von Daten durchzuführen.

Description

TECHNISCHES GEBIET
Die vorliegende Erfindung betrifft allgemein Datenverarbeitungssysteme und insbesondere ein Bereitstellen eines direkten Zugriffs zwischen Beschleunigern und nichtflüchtigem Haupt- und Massenspeicher in einer Datenverarbeitungsumgebung.
HINTERGRUND
Eine gängige Form der Datenverarbeitung in großem Maßstab ist Cloud-Computing, bei dem Ressourcen über ein Datenübertragungssystem wie zum Beispiel ein Computernetzwerk interagieren und/oder zugänglich sein können. Bei Ressourcen kann es sich um durch Software wiedergegebene Simulationen und/oder Emulationen von Datenverarbeitungseinheiten, Speichereinheiten, Anwendungen und/oder anderen computerbezogenen Einheiten und/oder Diensten handeln, die auf einer oder mehreren Datenverarbeitungseinheiten wie zum Beispiel einem Server ausgeführt werden. Zum Beispiel kann eine Mehrzahl von Servern Daten austauschen und/oder gemeinsam nutzen, die je nach einer Menge an Verarbeitungsleistung, Speicherplatz und/oder anderen Datenverarbeitungsressourcen, die zum Durchführen von angeforderten Aufgaben benötigt werden, über Server hinweg erweitert und/oder verringert werden können. Das Wort „Cloud“ (engl. für „Wolke“) bezieht sich auf das wolkenförmige Erscheinungsbild eines Schaubilds der gegenseitigen Verbindungen zwischen Datenverarbeitungseinheiten, Computernetzwerken und/oder anderen computerbezogenen Einheiten, die in einer derartigen Anordnung interagieren.
KURZDARSTELLUNG
Es werden verschiedene Aspekte zum Bereitstellen eines direkten Zugriffs auf einen nichtflüchtigen Speicher in einer Datenverarbeitungsumgebung bereitgestellt. In einem Aspekt wird ein Verfahren zum Bereitstellen eines direkten Zugriffs zwischen Beschleunigern und auf einen nichtflüchtigen Speicher in einer Datenverarbeitungsumgebung, wiederum durch einen Prozessor, bereitgestellt. Einem oder mehreren Beschleunigern (z.B. Grafikprozessoreinheiten, „GPUs“) kann über eine Schnittstelle zur Anwendungsprogrammierung („API“) ein direkter Zugriff auf einen nichtflüchtigen Speicher unabhängig von einer zentralen Host-Verarbeitungseinheit („CPU“) auf einem Steuerpfad oder Datenpfad bereitgestellt werden, um einen Arbeitsschritt des Lesens und einen Arbeitsschritt des Schreibens von Daten durchzuführen.
Figurenliste
Damit die Vorteile der Erfindung ohne Weiteres verstanden werden, wird eine ausführlichere Beschreibung der oben kurz beschriebenen Erfindung unter Bezugnahme auf spezifische Ausführungsformen angeführt, die in den beigefügten Zeichnungen veranschaulicht werden. Unter dem Verständnis, dass diese Zeichnungen lediglich typische Ausführungsformen der Erfindung darstellen und deshalb nicht als deren Umfang einschränkend anzusehen sind, wird die Erfindung durch die Verwendung der beigefügten Zeichnungen mit zusätzlicher Genauigkeit und Ausführlichkeit erläutert. Es zeigen:

1 ein Blockschaubild, das einen beispielhaften Datenverarbeitungsknoten gemäß einer Ausführungsform der vorliegenden Erfindung darstellt;
2 ein zusätzliches Blockschaubild, das eine beispielhafte Cloud-Computing-Umgebung gemäß einer Ausführungsform der vorliegenden Erfindung darstellt;
3 ein zusätzliches Blockschaubild, das Abstraktionsmodellschichten gemäß einer Ausführungsform der vorliegenden Erfindung darstellt;
4 ein Cloud-Computing-Netzwerk, in dem verschiedene Aspekte der vorliegenden Erfindung umgesetzt werden können;
5A bis 5C Blockschaubilder, die einen beispielhaften Arbeitsschritt zum Bereitstellen eines direkten Zugriffs zwischen Beschleunigern und auf einen nichtflüchtigen Speicher in einer Datenverarbeitungsumgebung gemäß Aspekten der vorliegenden Erfindung darstellen;
6 ein Blockschaubild, das eine beispielhafte Organisation eines Beschleuniger-Seitencaches und eine Schnittstelle zur Anwendungsprogrammierung („API“) darstellt, in der verschiedene Aspekte der vorliegenden Erfindung realisiert werden können;
7A bis 7C eine Tabelle, die Beschreibungen von Aufrufen der Schnittstelle zur Anwendungsprogrammierung („API“) zur Verwendung mit einem Beschleuniger darstellt, in dem verschiedene Aspekte der vorliegenden Erfindung realisiert werden können; und
8 einen Ablaufplan, der ein beispielhaftes Verfahren zum Bereitstellen eines direkten Zugriffs zwischen Beschleunigern und auf einen nichtflüchtigen Speicher in einer Datenverarbeitungsumgebung darstellt, in der wiederum verschiedene Aspekte der vorliegenden Erfindung realisiert werden können.

AUSFÜHRLICHE BESCHREIBUNG
Derzeit setzen viele Computersysteme Beschleuniger ein (z.B. Co-Prozessoren wie zum Beispiel grafische Verarbeitungseinheiten (GPUs, Graphical Processing Units)), um die Leistung eines derartigen Systems zu erhöhen, wobei Programme sowohl auf zentralen Datenverarbeitungseinheiten („CPU“) als auch auf den Beschleunigern laufen. Zum Beispiel können sich GPUs an dem Durchführen von komplexen mathematischen Berechnungen beteiligen. Auch ermöglicht die parallele Struktur von Beschleunigern es ihnen, bei Anwendungen/Arbeitsschritten, die möglicherweise große Datenblöcke verarbeiten, effektiver zu sein als CPUs.
Zudem werden Anwendungsdaten derzeit in einem nichtflüchtigen Speicher gespeichert, da die Daten häufig zu groß sind, um sie in dem GPU/CPU-Speicher zu speichern. Da der nichtflüchtige Speicher von der CPU verwaltet wird, verwaltet entweder die CPU den GPU-Speicher (durch mehrere Speicherkopien und Kernel-Aufrufe) oder der GPU-Kernel muss die CPU auffordern, ihm Daten bereitzustellen, was eine Synchronisierung mit der CPU und eine Warteschlange von Anfragen erfordert. Da es sich bei GPUs um Einheiten mit hohem Durchsatz handelt, wird eine große Anzahl von Threads gleichzeitig ausgeführt. Da alle parallelen Threads auf Daten warten könnten, liegen große Latenzen vor und treten auf. Sobald ein Block auf einem Streaming-Multiprozessor („SM“) einer GPU eingeplant ist, verbleibt der Block dort, bis er abgeschlossen ist. Wenn die Threads gezwungen sind, auf Daten zu warten, werden Ausführungsressourcen zurückgehalten und Blöcke, deren Daten verfügbar sind, können nicht ausgeführt werden. Von daher werden GPU-Ressourcen ineffizient verwaltet, und es kommt zu unnötigen Arbeitsschritten bei der Synchronisierung mit der Host-CPU und beim Warten auf Daten.
Daher ist ein Versorgen oder Bereitstellen von Beschleunigern wie zum Beispiel GPUs mit Daten mit geringer Latenz und hoher Bandbreite zu einem Engpass bei datenintensiven Anwendungen geworden. Wie bereits erwähnt, sind Beschleuniger wie zum Beispiel GPUs derzeit auf eine zentrale Host-Verarbeitungseinheit („CPU“) angewiesen, um den Speicher des Beschleunigers zu verwalten und auf nichtflüchtige Speicher zurückzugreifen, um den Beschleunigern Daten bereitzustellen. Dadurch entstehen nicht nur zusätzliche Aufwände für das Kopieren von Daten, sondern auch Aufwände für das Steuern in Form einer Synchronisierung zwischen dem Beschleuniger mit hohem Durchsatz und der CPU. Zusätzlich erfordert dies nicht nur zusätzliche Host-Ressourcen, sondern kann angesichts der Zugriffslatenzen im Submikrosekundenbereich bei modernen nichtflüchtigen Express-Speicher- („NVMe“-, Non-Volatile Memory Express-) Einheiten die Latenz um eine Größenordnung erhöhen und die Datenzugriffsbandbreite erheblich verringern, wie nachstehend in 5A veranschaulicht ist.
Um die niedrige Latenz/hohe Bandbreite von NVMe-Einheiten mit großer Kapazität voll auszuschöpfen, ermöglichen verschiedene Ausführungsformen der vorliegenden Erfindung ein direktes Zugreifen von Beschleunigern wie zum Beispiel GPUs auf diese Einheiten, ohne eine Einbindung der Host-CPU in die Steuerungs- oder Datenebene. In einem Aspekt kann einem oder mehreren Beschleunigern (z.B. Grafikprozessoreinheiten, „GPUs“) über eine Schnittstelle zur Anwendungsprogrammierung („API“) ein direkter Zugriff auf einen nichtflüchtigen Speicher unabhängig von einer zentralen Host-Verarbeitungseinheit („CPU“) auf einem Steuerpfad oder Datenpfad bereitgestellt werden, um einen Arbeitsschritt des Lesens und einen Arbeitsschritt des Schreibens von Daten durchzuführen.
Daher erhöhen die verschiedenen hierin beschriebenen Ausführungsformen die Datenverarbeitungseffizienz und die Nutzung von auf einer GPU verfügbaren Recheneinheiten, da die Speicherkapazität der GPU aktuell nicht mit der Rechenkapazität der GPU übereinstimmt. Außerdem entlastet die vorliegende Erfindung die CPUs, so dass sie parallel andere nützliche Aufgaben erledigen können, anstatt nur die Datenübertragungen zwischen GPUs und dem Speicher zu verwalten. Die vorliegende Erfindung stellt darüber hinaus Kosteneinsparungen und eine Verringerung des Stromverbrauchs der Datenverarbeitung dar, indem sie den GPU-Threads einen direkten Zugriff auf Terabytes an nichtflüchtigem Speicher bereitstellt und es GPU-Threads auch ermöglicht, den GPU-Speicher zu verwalten, anstatt auf die CPU für die GPU-Speicherverwaltung angewiesen zu sein, so dass die GPU-Threads nun direkt auf die von ihnen benötigten Daten zugreifen können.
Zusätzlich können die GPUs auch dann verwendet werden, wenn die Daten nicht in den GPU-Speicher passen, wodurch die GPUs für unregelmäßigere Anwendungen mit großen Daten (z.B. Verarbeitung großer Graphen) eingesetzt werden können. Darüber hinaus entfällt bei der vorliegenden Erfindung die Synchronisierung zwischen CPU und GPU, um mehr Daten an die GPU zu übertragen. Außerdem ermöglichen die hierin beschriebenen Arbeitsschritte des Vorablesens, dass GPU-Rechenressourcen frei sind, bis die Daten für die vorab gelesenen Blöcke in dem GPU-Speicher bereitstehen (z.B. sind die Daten für die angeforderten Datenblöcke in dem GPU-Speicher in einem Zustand vorhanden, in dem sie verwendet werden können). Zusätzlich ermöglicht die vorliegende Erfindung aufgrund der Tatsache, dass es nun eine geringere Abhängigkeit von der CPU gibt, ein Skalieren und mehr GPUs, ohne dass zusätzliche Kosten für das Erhöhen der Anzahl von Host-CPUs anfallen. Die vorliegende Erfindung verbessert darüber hinaus die Fehlertoleranz und -verwaltung und ermöglicht gleichzeitig die Fähigkeit zum gemeinsamen Planen von Aufgaben und E/A auf einer oder mehreren GPUs, um Überlastungen zu vermeiden und Lokalität zu nutzen.
Weitere Beispiele für verschiedene Aspekte der beschriebenen Ausführungsformen und entsprechende Vorteile werden hierin weiter beschrieben.
Es sei im Voraus darauf hingewiesen, dass ein Umsetzen der hierin angeführten Lehren nicht auf eine Cloud-Computing-Umgebung oder eine Internet-der-Dinge- (loT-) Netzwerkumgebung beschränkt ist, obwohl diese Offenbarung eine ausführliche Beschreibung von Cloud-Computing umfasst. Stattdessen können Ausführungsformen der vorliegenden Erfindung gemeinsam mit jeder beliebigen Art von jetzt bekannter oder später erfundener Datenverarbeitungsumgebung umgesetzt werden. Es sei darauf hingewiesen, dass es sich bei dem loT um ein neu entstehendes Konzept handelt, das Datenverarbeitungseinheiten einbezieht, die in Gegenstände wie zum Beispiel Geräte eingebettet und über ein Netzwerk verbunden sein können. Ein loT-Netzwerk kann eine oder mehrere loT-Einheiten oder „intelligente Einheiten“ umfassen, bei denen es sich um physische Objekte wie zum Beispiel Geräte mit darin eingebetteten Datenverarbeitungseinheiten handelt. Viele loT-Einheiten können eigenständig betrieben werden, aber sie können auch mit einem Steuerungssystem oder einem verteilten Steuerungssystem gekoppelt werden, wie zum Beispiel eines, das über eine Cloud-Computing-Umgebung läuft. Das Steuerungssystem kann einen Mechanismus zur durchgängigen Ablaufüberwachung umfassen, der dem hierin beschriebenen ähnelt.
Cloud-Computing ist ein Servicebereitstellungsmodell zum Ermöglichen eines problemlosen bedarfsgesteuerten Netzwerkzugriffs auf einen gemeinsam genutzten Pool von konfigurierbaren Datenverarbeitungsressourcen (z.B. Netzwerke, Netzwerkbandbreite, Server, Verarbeitung, Hauptspeicher, Speicher, Anwendungen, virtuelle Maschinen und Dienste), die mit minimalem Verwaltungsaufwand bzw. minimaler Interaktion mit einem Anbieter des Service schnell bereitgestellt und freigegeben werden können. Dieses Cloud-Modell kann mindestens fünf Eigenschaften umfassen, mindestens drei Dienstmodelle und mindestens vier Implementierungsmodelle.
Bei den Eigenschaften handelt es sich um die Folgenden:
On-Demand Self-Service: Ein Cloud-Nutzer kann einseitig automatisch nach Bedarf für Datenverarbeitungsfunktionen wie Serverzeit und Netzwerkspeicher sorgen, ohne dass eine menschliche Interaktion mit dem Anbieter der Dienste erforderlich ist.
Broad Network Access: Es sind Funktionen über ein Netzwerk verfügbar, auf die durch Standardmechanismen zugegriffen wird, welche die Verwendung durch heterogene Thin- oder Thick-Client-Plattformen (z.B. Mobiltelefone, Laptops und PDAs) unterstützen.
Resource-Pooling: Die Datenverarbeitungsressourcen des Anbieters werden zusammengeschlossen, um mehreren Nutzern unter Verwendung eines Multi-Tenant-Modells zu dienen, wobei verschiedene physische und virtuelle Ressourcen dynamisch nach Bedarf zugewiesen und neu zugewiesen werden. Es gibt eine gefühlte Standortunabhängigkeit, da der Nutzer allgemein keine Kontrolle bzw. Kenntnis über den genauen Standort der bereitgestellten Ressourcen hat, aber in der Lage sein kann, einen Standort auf einer höheren Abstraktionsebene festzulegen (z.B. Land, Staat oder Rechenzentrum).
Rapid Elasticity: Funktionen können für eine schnelle horizontale Skalierung (scale out) schnell und elastisch bereitgestellt werden, in einigen Fällen auch automatisch, und für ein schnelles Scale-in schnell freigegeben werden. Für den Nutzer erscheinen die für das Bereitstellen verfügbaren Funktionen häufig unbegrenzt und sie können jederzeit in jeder beliebigen Menge gekauft werden.
Measured Service: Cloud-Systeme steuern und optimieren die Verwendung von Ressourcen automatisch, indem sie eine Messfunktion auf einer gewissen Abstraktionsebene nutzen, die für die Art von Dienst geeignet ist (z.B. Speicher, Verarbeitung, Bandbreite sowie aktive Benutzerkonten). Die Nutzung von Ressourcen kann überwacht, gesteuert und gemeldet werden, wodurch sowohl für den Anbieter als auch für den Nutzer des verwendeten Dienstes Transparenz geschaffen wird.
Bei den Dienstmodellen handelt es sich um die Folgenden:
Software as a Service (SaaS): Die dem Nutzer bereitgestellte Funktion besteht darin, die in einer Cloud-Infrastruktur laufenden Anwendungen des Anbieters zu verwenden. Die Anwendungen sind über eine Thin-Client-Schnittstelle wie einen Web-Browser (z.B. auf dem Web beruhende E-Mail) von verschiedenen Client-Einheiten her zugänglich. Der Nutzer verwaltet bzw. steuert die zugrunde liegende Cloud-Infrastruktur nicht, darunter das Netzwerk, Server, Betriebssysteme, Speicher bzw. sogar einzelne Anwendungsfunktionen, mit der möglichen Ausnahme von eingeschränkten benutzerspezifischen Anwendungskonfigurationseinstellungen.
Platform as a Service (PaaS): Die dem Nutzer bereitgestellte Funktion besteht darin, durch einen Nutzer erstellte bzw. erhaltene Anwendungen, die unter Verwendung von durch den Anbieter unterstützten Programmiersprachen und Tools erstellt wurden, in der Cloud-Infrastruktur einzusetzen. Der Nutzer verwaltet bzw. steuert die zugrunde liegende Cloud-Infrastruktur nicht, darunter Netzwerke, Server, Betriebssysteme bzw. Speicher, hat aber die Kontrolle über die eingesetzten Anwendungen und möglicherweise über Konfigurationen des Application Hosting Environment.
Infrastructure as a Service (laaS): Die dem Nutzer bereitgestellte Funktion besteht darin, das Verarbeiten, Speicher, Netzwerke und andere grundlegende Datenverarbeitungsressourcen bereitzustellen, wobei der Nutzer in der Lage ist, beliebige Software einzusetzen und auszuführen, zu der Betriebssysteme und Anwendungen gehören können. Der Nutzer verwaltet bzw. steuert die zugrunde liegende Cloud-Infrastruktur nicht, hat aber die Kontrolle über Betriebssysteme, Speicher, eingesetzte Anwendungen und möglicherweise eine eingeschränkte Kontrolle über ausgewählte Netzwerkkomponenten (z.B. Host-Firewalls).
Bei den Einsatzmodellen handelt es sich um die Folgenden:
Private Cloud: Die Cloud-Infrastruktur wird einzig und allein für eine Organisation betrieben. Sie kann durch die Organisation oder einen Dritten verwaltet werden und kann sich in den eigenen Räumen oder in fremden Räumen befinden.
Community Cloud: Die Cloud-Infrastruktur wird von mehreren Organisationen gemeinsam genutzt und unterstützt eine spezielle Benutzergemeinschaft, die gemeinsame Angelegenheiten hat (z.B. Mission, Sicherheitsanforderungen, Richtlinien sowie Überlegungen bezüglich der Einhaltung von Vorschriften). Sie kann durch die Organisationen oder einen Dritten verwaltet werden und kann in den eigenen Räumen oder fremden Räumen stehen.
Public Cloud: Die Cloud-Infrastruktur wird der allgemeinen Öffentlichkeit oder einer großen Industriegruppe zur Verfügung gestellt und sie gehört einer Cloud-Dienste verkaufenden Organisation.
Hybrid Cloud: Die Cloud-Infrastruktur ist eine Zusammensetzung aus zwei oder mehreren Clouds (privat, Benutzergemeinschaft oder öffentlich), die zwar einzelne Einheiten bleiben, aber durch eine standardisierte oder proprietäre Technologie miteinander verbunden sind, die Daten- und Anwendungsportierbarkeit ermöglicht (z.B. Cloud-Zielgruppenverteilung für den Lastenausgleich zwischen Clouds).
Eine Cloud-Computing-Umgebung ist dienstorientiert mit Fokus auf Statusunabhängigkeit, geringer Kopplung, Modularität und semantischer Interoperabilität. Im Herzen von Cloud-Computing liegt eine Infrastruktur, die ein Netzwerk aus zusammengeschalteten Knoten aufweist.
Unter Bezugnahme auf 1 ist eine schematische Abbildung eines Beispiels eines Cloud-Computing-Knotens gezeigt. Der Cloud-Computing-Knoten 10 ist lediglich ein Beispiel eines geeigneten Cloud-Computing-Knotens und soll keinerlei Einschränkungen hinsichtlich des Anwendungsbereichs oder der Funktionalität von Ausführungsformen der hierin beschriebenen Erfindung andeuten. Trotzdem kann eine beliebige vorstehend dargelegte Funktionalität in dem Cloud-Computing-Knoten 10 umgesetzt und/oder von diesem durchgeführt werden.
In dem Cloud-Computing-Knoten 10 gibt es ein Computersystem/einen Server 12, das/der mit zahlreichen anderen Universal- oder Spezial-Datenverarbeitungssystem-Umgebungen bzw. -Konfigurationen betriebsfähig ist. Zu Beispielen für allgemein bekannte Datenverarbeitungssysteme, -umgebungen und/oder -konfigurationen, die zur Verwendung mit dem Computersystem/Server 12 geeignet sein können, gehören Personal ComputerSysteme, Server-Computersysteme, Thin Clients, Thick Clients, Handheld- bzw. Laptop-Geräte, Multiprozessorsysteme, auf Mikroprozessoren beruhende Systeme, Set-Top-Boxen, programmierbare Verbraucherelektronik, Netzwerk-PCs, Minicomputersysteme, Mainframe-Computersysteme sowie verteilte Cloud-Computing-Umgebungen, die irgendeine(s) der obigen Systeme bzw. Einheiten enthalten, und dergleichen, aber nicht darauf beschränkt.
Das Computersystem/der Server 12 kann in dem allgemeinen Kontext von durch Computersysteme ausführbaren Anweisungen, z.B. Programmmodulen, beschrieben werden, die von einem Computersystem ausgeführt werden. Allgemein können zu Programmmodulen Routinen, Programme, Objekte, Komponenten, Logik, Datenstrukturen und so weiter gehören, die bestimmte Aufgaben durchführen bzw. bestimmte abstrakte Datentypen umsetzen. Das Computersystem/der Server 12 kann in verteilten Cloud-Computing-Umgebungen ausgeführt werden, wo Aufgaben durch entfernt angeordnete Verarbeitungseinheiten durchgeführt werden, die über ein Datenübertragungsnetzwerk oder loT-Netzwerk verbunden sind. In einer verteilten Cloud-Computing-Umgebung können sich Programmmodule sowohl in lokalen als auch in entfernt angeordneten Computersystem-Speichermedien befinden, darunter Hauptspeichereinheiten.
Wie in 1 gezeigt ist, ist das Computersystem/der Server 12 in dem Cloud-Computing-Knoten 10 in Form einer Universal-Datenverarbeitungseinheit gezeigt. Die Komponenten des Computersystems/Servers 12 können eine(n) oder mehrere Prozessoren oder Verarbeitungseinheiten 16, einen Systemspeicher 28 und einen Bus 18 aufweisen, der verschiedene Systemkomponenten, darunter den Systemspeicher 28, mit dem Prozessor 16 verbindet, sind aber nicht darauf beschränkt.
Der Bus 18 stellt eine oder mehrere einer beliebigen von mehreren Arten von Busstrukturen dar, darunter ein Speicherbus oder eine Speichersteuereinheit, ein Peripheriebus, ein beschleunigter Grafikanschluss und ein Prozessor- oder lokaler Bus, die eine beliebige aus einer Vielfalt von Busarchitekturen verwenden. Zu derartigen Architekturen gehören als Beispiel und nicht als Einschränkung ein ISA-Bus (Industry Standard Architecture), ein MCA-Bus (Micro Channel Architecture), ein EISA-Bus (Enhanced ISA), ein VESA-Lokalbus (Video Electronics Standards Association) sowie ein PCI-Bus (Peripheral Component Interconnects).
Das Computersystem/der Server 12 umfasst üblicherweise eine Vielfalt von durch ein Computersystem lesbaren Medien. Bei derartigen Medien kann es sich um jedes beliebige verfügbare Medium handeln, auf welches das Computersystem/der Server 12 zugreifen kann, und es umfasst sowohl flüchtige als auch nichtflüchtige Medien, austauschbare und nicht austauschbare Medien.
Der Systemspeicher 28 kann durch ein Computersystem lesbare Medien in Form eines flüchtigen Speichers wie zum Beispiel einen Direktzugriffsspeicher (RAM) 30 und/oder Cachespeicher 32 enthalten. Das Computersystem/der Server 12 kann darüber hinaus andere austauschbare/nicht austauschbare, flüchtige/nichtflüchtige Computersystem-Speichermedien umfassen. Lediglich als Beispiel kann das Speichersystem 34 zum Lesen von und zum Schreiben auf ein nicht austauschbares, nichtflüchtiges magnetisches Medium bereitgestellt werden (das nicht gezeigt ist und üblicherweise „Festplattenlaufwerk“ genannt wird). Es können auch ein Magnetplattenlaufwerk zum Lesen von und zum Schreiben auf eine austauschbare, nichtflüchtige Magnetplatte (z.B. eine „Floppy-Diskette“) und ein optisches Plattenlaufwerk zum Lesen von oder zum Schreiben auf eine austauschbare, nichtflüchtige optische Platte wie zum Beispiel eine CD-ROM, DVD-ROM oder ein anderes optisches Medium bereitgestellt werden, auch wenn diese nicht gezeigt sind. In derartigen Fällen können sie jeweils über eine oder mehrere Datenmedienschnittstellen mit dem Bus 18 verbunden sein. Wie nachfolgend weiter dargestellt und beschrieben wird, kann der Systemspeicher 28 mindestens ein Programmprodukt enthalten, das einen Satz von Programmmodulen (z.B. mindestens einen) aufweist, die so konfiguriert sind, dass sie die Funktionen von Ausführungsformen der Erfindung ausführen.
Als Beispiel und nicht als Einschränkung können ein Programm/Dienstprogramm 40 mit (mindestens) einem Satz von Programmmodulen 42 sowie ein Betriebssystem, ein oder mehrere Anwendungsprogramme, andere Programmmodule und Programmdaten in dem Systemspeicher 28 gespeichert sein. Das Betriebssystem, das eine oder die mehreren Anwendungsprogramme, andere Programmmodule und Programmdaten oder eine beliebige Kombination daraus können jeweils eine Umsetzung einer Netzwerkumgebung aufweisen. Die Programmmodule 42 führen allgemein die hierin beschriebenen Funktionen und/oder Methodiken von Ausführungsformen der Erfindung aus.
Das Computersystem/der Server 12 kann auch mit einer oder mehreren externen Einheiten 14 wie zum Beispiel einer Tastatur, einer Zeigeeinheit, einer Anzeige 24 usw., einer oder mehreren Einheiten, die es einem Benutzer ermöglichen, mit dem Computersystem/Server 12 zu interagieren, und/oder beliebigen Einheiten (z.B. Netzwerkkarten, Modems usw.) Daten austauschen, die es dem Computersystem/Server 12 ermöglichen, mit einer oder mehreren anderen Datenverarbeitungseinheiten Daten auszutauschen. Ein derartiger Datenaustausch kann über Eingabe/Ausgabe- (E/A-) Schnittstellen 22 erfolgen. Außerdem kann das Computersystem/der Server 12 über einen Netzwerkadapter 20 mit einem oder mehreren Netzwerken Daten austauschen, wie zum Beispiel einem lokalen Netzwerk (LAN), einem allgemeinen Weitverkehrsnetz (WAN), ein loT-Netzwerk und/oder einem öffentlichen Netzwerk (z.B. dem Internet). Wie dargestellt ist, tauscht der Netzwerkadapter 20 mit den anderen Komponenten des Computersystems/Servers 12 über den Bus 18 Daten aus. Es sollte klar sein, dass andere Hardware- und/oder Software-Komponenten in Verbindung mit dem Computersystem/Server 12 verwendet werden könnten, auch wenn diese nicht gezeigt sind. Zu Beispielen gehören folgende, ohne auf diese beschränkt zu sein: Mikrocode, Einheitentreiber, redundante Verarbeitungseinheiten, externe Festplattenlaufwerk-Arrays, RAID-Systeme, Bandlaufwerke und Speichersysteme zur Datenarchivierung usw.
Unter Bezugnahme auf 2 ist eine veranschaulichende Cloud-Computing-Umgebung 50 abgebildet. Wie gezeigt ist, weist die Cloud-Computing-Umgebung 50 einen oder mehrere Cloud-Computing-Knoten 10 auf, mit denen von Cloud-Nutzern verwendete lokale Datenverarbeitungseinheiten wie ein elektronischer Assistent (PDA, personal digital assistant) oder ein Mobiltelefon 54A, ein Desktop-Computer 54B, ein Laptop-Computer 54C, eine intelligente („smarte“) Matratze 54D und/oder ein Automobil-Computer-System 54N Daten austauschen können. Wie hierin verwendet, kann es sich bei einer Matratze wie zum Beispiel der Matratze 54D um eine Unterlage, eine Matte, ein Kissen, einen Schaumstoff oder ein Objekt handeln, das dazu bestimmt ist, einen Körper ganz oder teilweise zu stützen oder zu tragen, wie zum Beispiel ein Bett (oder einen Teil eines Bettes), eine Couch, ein Sofa, einen Liegesessel, einen Sitz, einen Stuhl oder einen Sitz.
Die Knoten 10 können miteinander Daten austauschen. Sie können physisch oder virtuell in ein oder mehrere Netzwerke wie private, Benutzergemeinschafts-, öffentliche oder hybride Clouds gruppiert werden (nicht gezeigt), wie vorstehend beschrieben wurde, oder in eine Kombination daraus. Dies ermöglicht es der Cloud-Computing-Umgebung 50, Infrastruktur, Plattformen und/oder Software als Dienst anzubieten, für die ein Cloud-Nutzer keine Ressourcen auf einer lokalen Datenverarbeitungseinheit vorhalten muss. Es sei darauf hingewiesen, dass die Arten von in 2 gezeigten Datenverarbeitungseinheiten 54A bis N lediglich veranschaulichend sein sollen und dass die Datenverarbeitungsknoten 10 und die Cloud-Computing-Umgebung 50 über eine beliebige Art Netzwerk und/oder über eine beliebige Art von über ein Netzwerk aufrufbarer Verbindung (z.B. unter Verwendung eines Web-Browsers) mit einer beliebigen Art von computergestützter Einheit Daten austauschen können.
Unter Bezugnahme auf 3 wird ein Satz von funktionalen Abstraktionsschichten gezeigt, die durch die Cloud-Computing-Umgebung 50 (2) bereitgestellt werden. Es sollte von vornherein klar sein, dass die in 3 gezeigten Komponenten, Schichten und Funktionen lediglich veranschaulichend sein sollen und Ausführungsformen der Erfindung nicht darauf beschränkt sind. Wie abgebildet ist, werden die folgenden Schichten und entsprechenden Funktionen bereitgestellt:
Eine Einheitenschicht 55 enthält physische und/oder virtuelle Einheiten, die in Elektronik, Sensoren, Aktuatoren und anderen Objekten eingebettet und/oder eigenständig sind, um verschiedene Aufgaben in einer Cloud-Computing-Umgebung 50 durchzuführen. Jede der Einheiten in der Einheitenschicht 55 schließt Vernetzungsfähigkeiten mit anderen funktionalen Abstraktionsschichten ein, so dass diesen von den Einheiten erhaltene Informationen bereitgestellt werden können und/oder den Einheiten Informationen von den anderen Abstraktionsschichten bereitgestellt werden können. In einer Ausführungsform können die verschiedenen Einheiten, die in der Einheitenschicht 55 enthalten sind, ein Netzwerk von Entitäten einschließen, das insgesamt als „Internet der Dinge“ (loT, Internet of Things) bekannt ist. Ein derartiges Netzwerk von Entitäten ermöglicht das übergreifende Austauschen, Sammeln und Verbreiten von Daten, um eine große Vielfalt von Zwecken zu erfüllen, wie ein Fachmann verstehen wird.
Die Einheitenschicht 55 enthält, wie gezeigt, einen Sensor 52, einen Aktuator 53, einen „lernenden“ Thermostat 56 mit integrierter Verarbeitungs-, Sensor- und Netzwerkelektronik, eine Kamera 57, eine steuerbare Haushaltssteckdose/-steckbuchse 58 und einen steuerbaren elektrischen Schalter 59, wie gezeigt. Zu anderen möglichen Einheiten können verschiedene zusätzliche Sensoreinheiten, Netzwerkeinheiten, elektronische Einheiten (wie zum Beispiel eine Fernsteuereinheit), zusätzliche Aktuatoreinheiten, sogenannte „intelligente“ Vorrichtungen wie zum Beispiel ein Kühlschrank oder eine Waschmaschine/ein Trockner und eine große Vielfalt an anderen möglichen miteinander verbundenen Objekten gehören, aber nicht auf diese beschränkt.
Eine Hardware- und Software-Schicht 60 umfasst Hardware- und Software-Komponenten. Zu Beispielen für Hardware-Komponenten gehören: Mainframe-Computer 61; auf der RISC- (Reduced Instruction Set Computer) Architektur beruhende Server 62; Server 63; Blade-Server 64; Speichereinheiten 65; und Netzwerke sowie Netzwerkkomponenten 66. In einigen Ausführungsformen umfassen Software-Komponenten eine Netzwerk-Anwendungsserver-Software 67 und eine Datenbank-Software 68.
Eine Virtualisierungsschicht 70 stellt eine Abstraktionsschicht bereit, aus der die folgenden Beispiele für virtuelle Einheiten bereitgestellt werden können: virtuelle Server 71, virtueller Speicher 72, virtuelle Netzwerke 73, darunter virtuelle private Netzwerke, virtuelle Anwendungen und Betriebssysteme 74; und virtuelle Clients 75.
In einem Beispiel kann eine Verwaltungsschicht 80 die nachfolgend beschriebenen Funktionen bereitstellen. Eine Ressourcen-Bereitstellung 81 stellt die dynamische Beschaffung von Datenverarbeitungsressourcen sowie anderen Ressourcen bereit, die zum Durchführen von Aufgaben innerhalb der Cloud-Computing-Umgebung verwendet werden. Ein Messen und eine Preisfindung 82 stellen die Kostenverfolgung beim Verwenden von Ressourcen innerhalb der Cloud-Computing-Umgebung sowie die Abrechnung oder Rechnungsstellung für den Verbrauch dieser Ressourcen bereit. In einem Beispiel können diese Ressourcen Anwendungs-Software-Lizenzen aufweisen. Eine Sicherheit stellt die Identitätsüberprüfung für Cloud-Nutzer und Aufgaben sowie Schutz für Daten und andere Ressourcen bereit. Ein Benutzerportal 83 stellt Nutzern und Systemadministratoren den Zugang zu der Cloud-Computing-Umgebung bereit. Eine Verwaltung des Dienstumfangs 84 stellt die Zuordnung und Verwaltung von Cloud-Computing-Ressourcen bereit, so dass die benötigten Dienstziele erreicht werden. Ein Planen und Erfüllen von Vereinbarungen zum Dienstumfang (SLA, Service Level Agreement) 85 stellt die Anordnung vorab und die Beschaffung von Cloud-Computing-Ressourcen, für die eine zukünftige Anforderung vorausgesehen wird, gemäß einem SLA bereit.
Eine Arbeitslastschicht 90 stellt Beispiele für die Funktionalität bereit, für welche die Cloud-Computing-Umgebung verwendet werden kann. Zu Beispielen für Arbeitslasten und Funktionen, die von dieser Schicht bereitgestellt werden können, gehören: Abbildung und Navigation 91; Software-Entwicklung und Lebenszyklusverwaltung 92; Bereitstellung von Ausbildung in virtuellen Klassenzimmern 93; Datenanalytikverarbeitung 94; Transaktionsverarbeitung 95; und im Zusammenhang mit den dargestellten Ausführungsformen der vorliegenden Erfindung verschiedene Arbeitslasten und Funktionen 96 zum Bereitstellen eines direkten Zugriffs zwischen Beschleunigern und auf einen nichtflüchtigen Speicher. Zusätzlich können die Arbeitslasten und Funktionen 96 zum Bereitstellen eines direkten Zugriffs zwischen Beschleunigern und auf einen nichtflüchtigen Speicher Arbeitsschritte umfassen wie zum Beispiel Datenanalyse (darunter Datenerfassung und -verarbeitung von verschiedenen Umgebungssensoren), Vernetzung, Senden/Empfangen von Daten, Bereitstellen von Virtualisierung/virtuellem Rechnen, Cloud-Computing-Datenaustausch und/oder Verwaltungsfunktionen. Ein Fachmann wird verstehen, dass die Arbeitslasten und Funktionen 96 zum Bereitstellen eines direkten Zugriffs zwischen Beschleunigern und auf einen nichtflüchtigen Speicher auch in Verbindung mit anderen Teilen der verschiedenen Abstraktionsschichten funktionieren können, wie zum Beispiel die in der Hardware und Software 60, der Virtualisierung 70, der Verwaltung 80 und den anderen Arbeitslasten 90 (wie zum Beispiel die Datenanalytikverarbeitung 94), um die verschiedenen Zwecke der veranschaulichten Ausführungsformen der vorliegenden Erfindung zu erfüllen.
Wie bereits erwähnt, stellen die Mechanismen der vorliegenden Erfindung einen neuen Ansatz zum Bereitstellen eines direkten Zugriffs zwischen Beschleunigern und auf einen nichtflüchtigen Speicher in einer Datenverarbeitungsumgebung, wiederum durch einen Prozessor, bereit. Einem oder mehreren Beschleunigern (z.B. Grafikprozessoreinheiten, „GPUs“) kann über eine Schnittstelle zur Anwendungsprogrammierung („API“) ein direkter Zugriff auf einen nichtflüchtigen Speicher unabhängig von einer zentralen Host-Verarbeitungseinheit („CPU“) auf einem Steuerpfad oder Datenpfad bereitgestellt werden, um einen Arbeitsschritt des Lesens und einen Arbeitsschritt des Schreibens von Daten durchzuführen.
Nun übergehend zu 4, ist ein Blockschaubild gezeigt, in dem beispielhafte funktionale Komponenten 400 gemäß verschiedenen Mechanismen der veranschaulichten Ausführungsformen dargestellt sind. In einem Aspekt können eine oder mehrere der in den 1 bis 3 beschriebenen Komponenten, Module, Dienste, Anwendungen und/oder Funktionen in 4 verwendet werden. Es wird ein Dienst 410 für direkten Datenzugriff gezeigt, der eine Verarbeitungseinheit 420 („Prozessor“) enthält, um verschiedene Rechen-, Datenverarbeitungs- und andere Funktionalitäten gemäß verschiedenen Aspekten der vorliegenden Erfindung durchzuführen. In einem Aspekt können sich der Prozessor 420 und ein Speicher 430 innerhalb und/oder außerhalb des Dienstes 410 für direkten Datenzugriff und innerhalb und/oder außerhalb des Datenverarbeitungssystems/Servers 12 befinden. Der Dienst 410 für direkten Datenzugriff kann, wie in 1 beschrieben, in dem Computersystem/Server 12 enthalten sein.
In einem Aspekt kann das Computersystem/der Server 12 mit einem oder mehreren Beschleunigern wie zum Beispiel GPUs 492 (nur beispielhaft dargestellt) und einem nichtflüchtigen Speicher 490 (z.B. einer Halbleiter-Speicherplatte „SDD“) Daten austauschen. In einem Aspekt können die GPUs 492 auf dem Computersystem/Server 12 umfasst sein (z.B. innerhalb und/oder außerhalb des Computersystems/Servers 12 angeordnet). Zusätzlich kann der nichtflüchtige Speicher 490 auf dem Computersystem/Server 12 enthalten sein (z.B. innerhalb und/oder außerhalb des Computersystems/Servers 12) und/oder der nichtflüchtige Speicher 490 kann sich außerhalb des Computersystems/Servers 12 befinden.
Die Verarbeitungseinheit 420 kann mit dem Speicher 430 Daten austauschen. Der Dienst 410 für direkten Datenzugriff kann eine Komponente 440 für direkten Datenzugriff, eine Seitencachekomponente 450, eine Vorablesenkomponente 460 und/oder eine Objektverwaltungskomponente 470 umfassen.
Wie ein Fachmann verstehen wird, dient die Darstellung der verschiedenen Funktionseinheiten in dem Dienst 410 für direkten Datenzugriff der Veranschaulichung, da sich die Funktionseinheiten innerhalb des Dienstes 410 für direkten Datenzugriff oder an einer anderen Stelle innerhalb und/oder zwischen verteilten Datenverarbeitungskomponenten befinden können.
In einem Aspekt kann der Dienst 410 für direkten Datenzugriff einem oder mehreren Beschleunigern über eine Schnittstelle zur Anwendungsprogrammierung („API“) einen direkten Zugriff auf einen nichtflüchtigen Speicher unabhängig von einer zentralen Host-Verarbeitungseinheit („CPU“) auf einem Steuerpfad oder Datenpfad bereitstellen, um einen Arbeitsschritt des Lesens und einen Arbeitsschritt des Schreibens von Daten durchzuführen.
Der Dienst 410 für direkten Datenzugriff kann ein(e) oder mehrere nichtflüchtige(s) Express-Speicher- („NVMe“-) Warteschlange(n) und -Register des nichtflüchtigen Speichers 490 in einem Speicheradressraum des einen oder der mehreren Beschleuniger zuordnen.
Die Seitencachekomponente 450 kann einen Seitencache verwenden, der von dem einen oder den mehreren Beschleunigern in dem Speicher des einen oder der mehreren Beschleuniger verwaltet wird, um Lokalität in den Daten zu nutzen. Falls mehrere Beschleuniger (z.B. mehrere GPUs) vorhanden sind, kann die Seitencachekomponente 450 einen verteilten Seitencache verwenden, der von einem oder mehreren Beschleunigern in dem Speicher einer Mehrzahl von Beschleunigern verwaltet wird, um Lokalität in den Daten zu nutzen.
Die Seitencachekomponente 450 kann eine oder mehrere Seiten aus dem nichtflüchtigen Speicher 490 in einen Seitencache kopieren und eine Seitenzuordnungstabelle aktualisieren. Der Dienst 410 für direkten Datenzugriff kann die Host-CPU beim Kopieren der Daten aus dem nichtflüchtigen Speicher 490 auf den einen oder die mehreren Beschleuniger wie zum Beispiel die GPUs 492 aus dem Steuerpfad oder Datenpfad entfernen.
Die Vorablesenkomponenten 460 können die Daten mit der API vorab lesen und jeden Rechenzyklus zum Überlagern der Berechnung und Bewegung der Daten einsparen .
Der Dienst 410 für direkten Datenzugriff kann in Verbindung mit der Seitencachekomponente 450 und/oder den Vorablesenkomponenten beim Empfangen eines oder mehrerer API-Aufrufe für den Arbeitsschritt des Lesens oder den Arbeitsschritt des Schreibens der Daten, der/die von dem einen oder den mehreren Beschleunigern eingeleitet wurde(n), ein Auftreten eines Seitencachefehlers ermitteln, eine oder mehrere Seiten aus einem oder mehreren nichtflüchtigen Express-Speicher- („NVMe“-) Datenpuffern in einen Seitencache kopieren und/oder eine Seitenzuordnungstabelle aktualisieren.
Die Objektverwaltungskomponente 470 in einer Host-CPU (z.B. dem Computersystem/Server 12, der/das sich innerhalb und/oder außerhalb der GPUs 492 befinden kann) kann eine Objektadresse für jedes Objekt in dem nichtflüchtigen Speicher 490 beim Starten einer Anwendung verwalten. Eine Zuordnung jeder Objektkennung („ID“), eine Startblockadresse des Objekts und eine Objektgröße können von der Host-CPU verwaltet und in einem reservierten Bereich des nichtflüchtigen Speichers 490 dauerhaft gespeichert werden. Die Arbeitsschritte von 800 können unter Verwendung einer oder mehrerer API-Aufrufe an den einen oder die mehreren Beschleuniger einen Teilbereich von Seiten für jedes Objekt zuweisen.
Zum Beispiel liest die Host-CPU (z.B. das Computersystem/der Server 12) beim Start einer Anwendung die Zuordnung unter Verwendung eines API-Aufrufs (z.B. des API-Aufrufs „get_object_map“). Bei einem Kernelaufruf übergibt die Host-CPU (z.B. das Computersystem/der Server 12) anstelle von Zeigern die Startblockadresse für jedes Objekt mit dessen Größe. Die GPUs 492 können dann über den Ort der gewünschten Datenstrukturen Bescheid wissen. Die Host-CPU (z.B. das Computersystem/der Server 12) kann unter Verwendung eines anderen API-Aufrufs (z.B. des API-Aufrufs „pcreate“) Platz und Zuordnungen für neue Objekte erstellen. Eine GPU wie zum Beispiel eine der GPUs 492 kann einem Teilbereich von Seiten für jedes der Objekte zugewiesen werden. Die GPU wie zum Beispiel eine der GPUs 492 kann als Basis (home) für diese Seiten bezeichnet werden (z.B. ist eine GPU eine Basis-GPU für eine Seite, wenn sie Eigentümerin dieser Seite ist).
Nun übergehend zu den 5A bis 5C, ist ein Blockschaubild einer beispielhaften Funktionalität 500 dargestellt, die sich auf ein Bereitstellen eines direkten Zugriffs zwischen Beschleunigern und auf einen nichtflüchtigen Speicher bezieht. Wie gezeigt, sind die verschiedenen Funktionsblöcke mit Pfeilen dargestellt, welche die Beziehungen der Blöcke 500 zueinander bezeichnen und den Prozessablauf zeigen. Zusätzlich werden auch beschreibende Informationen gezeigt, die jeden der Funktionsblöcke 500 (oder „Aktionsschritte“ oder einfach „Schritte“) betreffen. Wie man sehen wird, können viele der Funktionsblöcke auch als „Module“ einer Funktionalität betrachtet werden, in demselben beschreibenden Sinne, wie er zuvor in den 1 bis 4 beschrieben wurde. Angesichts der vorstehenden Ausführungen können die Modulblöcke 500 auch in verschiedene Hardware- und Softwarekomponenten eines Systems zum Bereitstellen eines direkten Zugriffs zwischen Beschleunigern und auf einen nichtflüchtigen Speicher gemäß der vorliegenden Erfindung integriert werden. Viele der Funktionsblöcke 500 können als Hintergrundprozesse auf verschiedenen Komponenten ausgeführt werden, entweder in verteilten Datenverarbeitungseinheiten oder auf der Benutzereinheit oder an einer anderen Stelle, und der Benutzer nimmt sie im Allgemeinen nicht wahr. Eine wiederholte Beschreibung von gleichartigen Elementen, Komponenten, Modulen, Diensten, Anwendungen und/oder Funktionen, die in anderen hierin beschriebenen Ausführungsformen eingesetzt werden, wird der Kürze halber weggelassen.
Wie bereits erwähnt, zeigt 5A eine GPU 510, die auf ein Host-Dateisystem „FS“ wie zum Beispiel eine Host-CPU 530 und einen dynamischen Direktzugriffsspeicher „DRAM“ der CPU angewiesen ist, um den Speicher der GPU 510 zu verwalten, und die auf einen nichtflüchtigen Speicher 520 angewiesen ist, um der GPU 510 Daten bereitzustellen. Dadurch entstehen nicht nur zusätzliche Aufwände für das Kopieren von Daten, sondern auch Aufwände für das Steuern in Form einer Synchronisierung zwischen dem Beschleuniger mit hohem Durchsatz und der CPU 530. Für die Host-CPU 530 entsteht ein Aufwand für die Speicherverwaltung zwischen der GPU 510 und dem nichtflüchtigen Speicher 520 der Schritte 1 und 2. Es können mehrere Kopien der Daten zwischen dem nichtflüchtigen Speicher 520 und der CPU 530 in Schritt 3 und zwischen der GPU 530 und der CPU 530 wie in Schritt 4 übergeben/zugeführt werden. Zusätzlich können GPU-Threads, -Blöcke und -Gitter angehalten werden, bis Daten wie in Schritt 4 an die GPU 510 übertragen werden. Es sei darauf hingewiesen, dass es Versuche gibt, die Aufwände beim Kopieren von Daten zu verringern, indem ein direkter Speicherzugriff („DMA“) direkt zwischen der GPU 510 und dem nichtflüchtigen Speicher 520 durchgeführt wird, was jedoch immer noch zu CPU-seitigen Aufwänden bei der Steuerung/Synchronisierung durch die CPU 530 führt.
Allerdings stellt 5B unter Verwendung der verschiedenen Ausführungsformen der vorliegenden Erfindung Arbeitsschritte zum Bereitstellen eines direkten Zugriffs zwischen Beschleunigern und auf einen nichtflüchtigen Speicher unter Verwendung eines einzelnen Beschleunigers (z.B. einer einzelnen GPU 510) dar. Das heißt, 5B zeigt ein Verringern des Aufwands/der Latenz des Zugriffs und ermöglicht GPU-Threads der GPU 510 ein direktes Zugreifen auf den nichtflüchtigen Speicher 520 unabhängig von der CPU 530. In einem Aspekt verwaltet die GPU 510 den nichtflüchtigen Speicher 520 mit einem Dateisystem „FS“ (ähnlich einem einfachen Objektspeicher) und nutzt einen NVMe-Treiber (z.B. unter Verwendung von GPU Direct), der auf der GPU 510 läuft. Die CPU 530 wird wie in Schritt 1 aus dem Steuerpfad und wie in Schritt 2 aus dem Datenpfad entfernt. Die GPU 510 hat Zugriff auf den gesamten nichtflüchtigen Speicher 520.
Insbesondere sind in 5B Arbeitsschritte dargestellt, bei denen Lese- und Schreibanfragen von einem einzelnen Beschleuniger wie zum Beispiel der GPU 510 gestellt werden, um den Aufwand/die Latenz des Zugriffs zu verringern und den GPU-Threads der GPU 510 ein direktes Zugreifen auf den nichtflüchtigen Speicher 520 unabhängig von der CPU 530 zu ermöglichen. In einem Aspekt kann eine API die GPU-Threads der GPU 510 in die Lage versetzen, Daten auf dem nichtflüchtigen Speicher 520 unter Verwendung von NVMe zu lesen und zu schreiben, ohne dass die Host-CPU 530 auf dem Steuer- oder Datenpfad beteiligt ist, wie in den folgenden Schritten veranschaulicht ist.
In Schritt 1 kann die Host-CPU 530 eine Schnittstelle (z. B. Warteschlangen und DMA) zwischen der GPU und dem nichtflüchtigen Speicher 520 (über NVMe und eine DMA-Zuordnung wie zum Beispiel GPUDirect/DirectGMA) initialisieren. In Schritt 2 kann die Host-CPU 530 die Übertragung einer Objektzuordnung von dem nichtflüchtigen Speicher 520 an den GPU-Speicher der GPU 510 einleiten, damit GPU-Threads wissen, wo sich jedes Objekt in dem nichtflüchtigen Speicher 520 befindet. In Schritt 2(1) kann ein Eintrag in der Zuordnung ein Schlüssel-Wert-Paar sein, mit einer Objektkennung („ID“) als Schlüssel und einer Startadresse in dem nichtflüchtigen Speicher 520 als Wert. In Schritt 2(2) kann eine Anwendung der Host-CPU 530 der GPU 510 angeben, welches Objekt verwendet werden soll, indem geeignete Objekt-IDs als Parameter an GPU-Kernel-Starts übergeben werden. In Schritt 3 kann die Host-CPU 530 GPU-Kernel wie zum Beispiel in einer normalen Anwendung starten, außer mit Objekt-IDs als Parameter (aus Schritt 2(2)).
In Schritt 4 können die GPU-Kernel-Threads unter Verwendung von einem oder mehreren API-Aufrufen wie zum Beispiel den bereitgestellten API-Aufrufen „pread“ und „pwrite“ Daten auf dem nichtflüchtigen Speicher 520 lesen und/oder in diesen schreiben.
In Schritt 5 kann, wenn ein GPU-Thread den API-Aufruf „pread“ ausgibt, ein GPU-Seitencache von dem GPU-Thread (z.B. dem Thread, der den API-Aufruf ausführt und von dem GPU-Thread überprüft wird) überprüft werden, um zu ermitteln, ob sich angeforderte Seiten in dem GPU-Speicher der GPU 510 befinden. In Schritt 5(1) werden, wenn sich die Seiten in dem Speicher der GPU 510 befinden, die Daten aus dem Seitencache in einen von einem Benutzer zugeordneten Zielpuffer kopiert (z.B. kann es sich bei dem Zielpuffer um einen von einem Benutzer zugeordneten Puffer in dem GPU-Speicher handeln, den der Benutzer lesen und in den er schreiben kann und der unter Verwendung von einer oder mehreren APIs zugeordnet werden kann). In Schritt 5(2) kann der aufrufende GPU-Thread, wenn sich die Seiten (oder eine Teilmenge von Seiten) nicht in einem GPU-Seitencache befinden, einen NVMe-Befehl für die fehlenden Seiten vorbereiten, wie in Schritt 5(2)(1), den NVMe-Befehl atomar der NVMe-Übermittlungswarteschlange hinzufügen und sich dem NVMe ankündigen, wie in Schritt 5(2)(2), ohne Verwendung der CPU 530 in dem Steuerpfad wie in Schritt 5(2)(2)(1), fragt die NVMe-Abschlusswarteschlange ab, bis die Anfrage abgeschlossen ist, wie in Schritt 5(2)(3), wobei die Daten zwischen der GPU 510 und der NVMe-Einheit ohne Einmischung der CPU 520 direkt untereinander kopiert werden, wie in Schritt 5(2)(3)(1), und kopiert Daten aus einem NVMe-IO-Pufferbereich in einen von dem Benutzer bereitgestellten Puffer wie in Schritt 5(2)(4) und aktualisiert einen Seitencachezustand, wie in Schritt 5(2)(5).
Zusätzlich kann der aufrufende Thread in Schritt 6, wenn ein GPU-Thread eine API „pwrite“ ausgibt, den Seitencachezustand aktualisieren, wie in Schritt (6)(1), einen NVMe-Befehl zum Schreiben von Seiten in einen nichtflüchtigen Speicher vorbereiten, wie in Schritt (6)(2), den Befehl atomar zur NVMe-Übermittlungswarteschlange hinzufügen und sich dem NVMe ankündigen, wie in Schritt (6)(3) (z.B. ohne Verwendung der CPU 530 in dem Steuerpfad) wie in Schritt (5)(2)(2)(1), fragt eine NVMe-Abschlusswarteschlange ab, bis die Anfrage abgeschlossen ist, wie in Schritt (6)(4) (z.B. werden die Daten zwischen der GPU 510 und der NVMe-Einheit ohne Einmischung der CPU 520 direkt untereinander kopiert), wie in Schritt (5)(2)(3)(1), und gibt seine Puffer frei, wie in Schritt (6)(7).
In Schritt 7 kann der GPU-Thread API-Aufrufe „pread“ und „pwrite“ so oft er will ausgeben, und die Schritte 1(5) und 1(6) können jeweils wiederholt werden.
Für den Fall, dass mehrere GPUs vorhanden sind, zeigt 5C Arbeitsschritte zum Bereitstellen eines direkten Zugriffs zwischen mehreren GPUs 510 (z.B. stellt 510 in 5C eine Gruppe von GPUs dar) und dem nichtflüchtigen Speicher 520. Vor einem Zugreifen auf den NVMe tauschen die GPUs 510 untereinander Daten aus, um zu prüfen, ob Daten bereits in einem anderen GPU-Cache vorhanden sind.
In einem Aspekt werden Objektseiten per Hashverfahren in einen oder mehrere spezifische GPUs 510 umgewandelt. Die GPUs 510 können entweder Eigentümer einer Objektseite sein, in welchem Fall sich die Objektseite in einem Cache der einen oder der mehreren konkreten GPUs 510 befinden können, oder die GPUs 510 können dafür verantwortlich sein, die Objektseite abzurufen. Außerdem können die GPUs 510 eine Seite von der Eigentümer-GPU der Gruppe von GPUs 510 anfordern.
Nun übergehend zu 6, zeigt ein Blockschaubild 600 beispielhafte Arbeitsschritte zum Verwenden einer Organisation eines Beschleuniger-Seitencaches und einer Schnittstelle zur Anwendungsprogrammierung („API“). In einem Aspekt kann jede/jedes/jeder der in den 1 bis 5A bis 5C beschriebenen Einheiten, Komponenten, Module, Arbeitsschritte und/oder Funktionen auch einen oder mehrere Arbeitsschritte oder Aktionen aus 6 anwenden oder durchführen.
In Schritt 1 kann ein API-Aufruf (z.B. ein API-Aufruf „pread“ und/oder eine API „pwrite“) an einen GPU-Seitencache („gpcache“) in einem GPU-Speicher 620 ausgegeben werden. In Schritt 2) Ermitteln eines Auftretens eines Seitencachefehlers und Übermitteln einer NVMe-Anfrage an eine NVMe-Übermittlungswarteschlange 624 zum Zugreifen auf eine NVMe-Einheit 630 beim Empfangen eines oder mehrerer API-Aufrufe (z.B. eines API-Aufrufs „pread“ und/oder eines API-Aufrufs „pwrite“) für den Arbeitsschritt des Lesens oder den Arbeitsschritt des Schreibens der Daten, die von dem einen oder den mehreren Beschleunigern (z.B. GPU-Thread 610) eingeleitet wurden. In Schritt 3 wird die Abfrage des Abschlusses der NVMe-Anfrage unter Verwendung der NVMe-Einheit 630 abgeschlossen und einer NVMe-Abschlusswarteschlange 626 bereitgestellt.
In Schritt 4 können Seiten aus den NVMe-Datenpuffern 628 in den Seitencache 622 kopiert und die Seiten/Objekt-Zuordnungstabelle aktualisiert werden.
Für den Fall, dass ein direkter Zugriff zwischen Beschleunigern und auf nichtflüchtige Speicher unter Verwendung eines einzelnen Beschleunigers (z.B. einer einzelnen GPU 510 aus 5B) bereitgestellt wird, können die folgenden Arbeitsschritte unter Verwendung eines Seitencaches (z.B. eines von der Anwendung/Software verwalteten Seitencaches) in dem GPU-Speicher durchgeführt werden, um Lokalität in Daten zu nutzen.
In Schritt 1) kann eine Seitentabelle in dem GPU-Speicher 620 (z.B. einem globalen GPU-Speicher) verwaltet werden, in der eine Zuordnung von Seiten von Objektdaten zu globalen GPU-Speicheradressen des GPU-Speichers 620 (z.B. einem globalen GPU-Speicher) gespeichert ist. In Schritt (1)(1) gibt es nur dann eine Zuordnung, wenn sich die Seite in dem GPU-Speicher 620 befindet.
In Schritt 2 können Seiten des Seitencaches in einer Liste von am längsten ungenutzten Seiten („LRU“, least recently used) geführt werden. In Schritt 2(1) können bei einer API-Anfrage „pread“ oder „write“, wenn nicht ausreichend viele freie Seiten vorhanden sind (z.B. nicht genügend freie Seiten), die LRU-Seiten zurückgeschrieben werden, wenn sie beschädigt, von der vorherigen Zuordnung gelöst und für eine neue Zuordnung neu zugeordnet sind.
In Schritt 3(1) kann bei einem API-Aufruf „pread“ nach jeder angeforderten Seite in dem Seitencache gesucht werden. Wenn sich Seiten in dem Seitencache befinden, können Daten von dort in den von einem Benutzer bereitgestellten Puffer kopiert werden, wie in Schritt 3(2). In Schritt 3(2) können Eingabe/Ausgabe- („E/A“-) Anfragen für Seiten erstellt werden, die sich nicht in dem Seitencache 622 befinden. In Schritt 3(2)(1) können Zuordnungen in der Seitentabelle für neu angeforderte Seiten erstellt werden.
In Schritt 4(1) werden bei einem API-Aufruf „pwrite“ Seiten aus der LRU-Liste des Seitencaches zugewiesen, Daten aus dem von einem Benutzer angegebenen Puffer werden auf diese Seiten kopiert, und Seitenzuordnungen für Zielseiten in einem Objekt in dem nichtflüchtigen Speicher 630 können aktualisiert werden, um auf die entsprechenden Seiten zu verweisen. In Schritt 4(2) kann ein Bit in einem Seitentabelleneintrag für die Seite(n) gesetzt werden, wenn eine E/A-Schreibanfrage abgeschlossen ist. In Schritt 4(2)(1) kann ein zusätzlicher Arbeitsschritt zum Zurückschreiben (aus Schritt 2(2)(4)(1)) im Falle einer Löschung durchgeführt werden. In Schritt 5) können ein oder mehrere Arbeitsschritte des Lesens/Schreibens durchgeführt werden.
Es sei darauf hingewiesen, dass für den Fall, dass ein direkter Zugriff zwischen Beschleunigern und auf einen nichtflüchtigen Speicher unter Verwendung mehrerer Beschleuniger (z.B. einer Gruppe der GPU 510 aus 5C unter Verwendung eines verteilten Seitencaches für eine Datenverarbeitungsumgebung mit mehreren GPUs) bereitgestellt wird, die folgenden Arbeitsschritte unter Verwendung eines Seitencaches (z.B. eines von Anwendungen/Software verwalteten Seitencaches) in dem GPU-Speicher durchgeführt werden können, um Lokalität in Daten zu nutzen.
In Schritt 1 kann eine GPU (z.B. die GPU 510 aus Figur 510) einem Teilbereich von Seiten für Objekte zugewiesen werden. Die GPU kann als die Basis für diese Seiten bezeichnet werden. In Schritt 1(1) kann jeder GPU auch eine eindeutige ID zugewiesen werden.
In Schritt 2 verwaltet/pflegt die Basis-GPU 510 eine Zuordnung derjenigen Seiten, für welche die GPU 510 als Basis gekennzeichnet ist. In Schritt 2(1) können die Arbeitsschritte des Zuordnens abbilden, welche anderen GPUs die Seite zwischengespeichert haben. Befindet sich die Seite in dem Seitencache einer GPU, können die GPU-ID und die Speicheradresse in Schritt 2(2)(2) innerhalb des Seitencaches dieser bestimmten GPU in der Gruppe von GPUs geführt werden. In Schritt 2(3) befindet sich die Seite, wenn sie sich nicht in dem Seitencache der GPU befindet, alternativ in dem nichtflüchtigen Speicher 520.
Wenn ein API-Aufruf „pread“ des GPU-Speichers 620 nicht in der Lage ist, die angeforderten Seiten in dem lokalen Seitencache zu finden, sendet der GPU-Speicher 620 in Schritt 3 eine Anfrage an die Basis-GPU(s) dieser Seiten. In Schritt 3(1) kann die Basis-GPU prüfen, ob sich die Seite in einem Seitencache einer anderen GPU befindet. Wenn sich die Seite in dem Seitencache einer anderen GPU befindet, kann der GPU-Speicher 620 in Schritt 3(1)(1) mit der GPU-ID und der Seitencacheadresse antworten, so dass die anfordernde GPU die Seite(n) aus dem Seitencache dieser GPU kopieren kann; andernfalls lässt die Basis-GPU die anfordernde GPU wissen, dass sich die Seiten in dem nichtflüchtigen Speicher 620 befinden, und aktualisiert ihre Zuordnungstabelle wie in Schritt 3(1)(2), und die anfordernde GPU stellt eine E/A-Anfrage wie in Schritt 3(2)(1).
Wenn der GPU-Thread 610 ein „pwrite“ auf einigen Seiten ausführt, sendet der GPU-Thread 610 in Schritt 4 eine Anfrage an die Basis-GPU(s) dieser Seiten. In Schritt 4(1) kann die Basis-GPU prüfen, ob andere GPUs die Seiten, die in Kürze überschrieben werden sollen, in ihrem Seitencache aufweisen. In Schritt 4(1)(1) kann die Basis-GPU, wenn andere GPUs die Seiten, die in Kürze überschrieben werden sollen, in ihrem Seitencache aufweisen, alle diese Seiten in den Seitencaches dieser alternativen GPUs ungültig machen und aktualisiert ihre eigene Zuordnung. In Schritt 4(1)(2) teilt die Heim-GPU der anfragenden GPU mit, dass sich die Seiten in dem nichtflüchtigen Speicher 630 befinden, wenn andere GPUs die Seiten, die in Kürze überschrieben werden sollen, nicht in ihrem Seitencache haben, und aktualisiert dahingehend, dass die Zuordnungstabelle aktualisiert wird, nachdem die anfragende GPU ihre E/A-Anfrage beendet hat. In Schritt 4(1)(2)(1) kann die anfragende GPU eine E/A-Anfrage stellen.
In Schritt 5 kann ein Thread auf jeder GPU speziell für das Bearbeiten von Anfragen von anderen GPUs vorgesehen sein.
Es sei darauf hingewiesen, dass die hierin beschriebenen Arbeitsschritte des Vorablesens (z.B. 4 bis 5B bis 5C) unter Verwendung eines oder mehrerer Arbeitsschritte durchgeführt werden können. Man betrachte zum Beispiel die folgenden beiden Arbeitsschritte zum Durchführen der Arbeitsschritte des Vorablesens.
In Arbeitsschritt 1 des Vorablesens können die folgenden Arbeitsschritte zum Vorablesen von Daten und deren Weitergabe zwischen Thread-Blöcken wie folgt durchgeführt werden. In Schritt 1 kann eine GPU wie zum Beispiel die GPU 510 einen oder mehrere Thread-Blöcke (im Folgenden als E/A-Blöcke bezeichnet) starten, die nur zum Ausgeben entsprechender E/A-Anfragen für die „preads“ dieses Blocks unter Verwendung des API-Aufrufs „pread_prefetch“ verantwortlich sind.
In Schritt 2 können die Threads in den E/A-Blöcken eine NVMe-Anfrage erstellen und übermitteln. In Schritt 2(1) können alle in den Schritten 1(5)(2)(1) bis 1(5)(2)(2) durchgeführten Aktionen für Lese- und Schreibanfragen von einer einzelnen GPU durchgeführt werden. In Schritt 2(2) fragt ein Thread nicht nach dem Abschluss (z.B. asynchron). In Schritt 2(3) kann ein Thread eine Zuordnung von E/A-Anfrage zu den NVMe-Befehls-IDs erstellen. Diese Zuordnung wird später von dem GPU-Thread verwendet, wenn er die Abschlusswarteschlange abfragt, um den Abschlusseintrag für den eingereichten Befehl zum Vorablesen zu finden.
Wenn ein echter Berechnen-Thread-Block geplant wird und die GPU-Threads einen API-Aufruf „pread“ tätigen, kann in Schritt 3 zunächst die Zuordnung überprüft werden, um festzustellen, ob die Anfrage bereits gestellt wurde, wie in Schritt 3(1). Wenn die Anfrage ausgegeben/erstellt wurde, fragt der GPU-Thread die NVMe-Abschlusswarteschlange 626 unter Verwendung eines API-Aufrufs „consume_prefetch_pread“ wie in Schritt 3(2) nach dieser NVMe-Befehls-ID ab; andernfalls fährt er wie in Schritt 3(3) fort (ähnlich wie die Schritte 1(5)(2)(4) für Lese- und Schreibanfragen von einer einzelnen GPU durchgeführt werden können). Auf diese Weise werden ein oder mehrere Zyklen der GPU-Streaming-Multiprozessoren („SMs“) nicht durch Warten auf den Abschluss einer E/A verschwendet.
In Arbeitsschritt 2 des Vorablesens können die folgenden Arbeitsschritte zum Vorablesen von Daten und zum Überlagern von Berechnungen und Datenbewegungen wie folgt durchgeführt werden. In Schritt 1 kann jeder GPU-Thread-Block gemultiplext werden, um die Berechnungen für mehrere Thread-Blöcke auszuführen.
In Schritt 2 kann der GPU-Thread-Block die ihm zugeordneten Mehrfach-Thread-Blöcke durch Pipelining der Blöcke verarbeiten.
In Schritt 3 kann ein GPU-Thread-Block die E/A-Anfrage für einen Block unter Verwendung des API-Aufrufs „pread_prefetch“ einleiten.
In Schritt 4 kann der GPU-Thread-Block die Berechnung für einen anderen Thread-Block mit dessen Daten in dem Puffer des Blocks ausführen.
In Schritt 5 kann der GPU-Thread-Block die Daten für die E/A-Anfrage, die für einen dritten Block gestellt wurde, unter Verwendung des API-Aufrufs „consume_prefetch_pread“ in den Puffer des Blocks einspeisen. In Schritt 5(1) kann die E/A-Anfrage für die hierin beschriebenen Schritte 3(2)(3) mit den Berechnungen in den Schritten 3(2)(4) überlagert werden.
In Schritt 6 kann jeder GPU-Thread-Block die Schritte 3(2)(2) bis zu den Schritten 3(2)(5) zur Verwendung des verteilten Seitencaches für die Datenverarbeitungsumgebung mit mehreren GPUs ausführen, bis alle Thread-Blöcke erschöpft sind.
Nun übergehend zu den 7A bis 7C, ist eine Tabelle 700 dargestellt, welche die Beschreibungen von Aufrufen der Schnittstelle zur Anwendungsprogrammierung („API“) zur Verwendung mit einer GPU veranschaulicht. In einem Aspekt kann jede/jedes/jeder der in den 1 bis 6 beschriebenen Einheiten, Komponenten, Module, Arbeitsschritte und/oder Funktionen auch einen oder mehrere API-Aufrufe aus den 7A bis 7C verwenden.
Ein API-Aufruf „initialize()“ kann zum Einrichten von GPUDirect/DirectGMA, zum Einrichten von NVMe-Warteschlangen und zum Zuordnen der NVMe-Warteschlangen in dem GPU-Speicher verwendet werden und fragt/ruft die NVMe-Warteschlangenzeiger und den Zustand, die an die GPU zu übergeben sind, ab.
Ein API-Aufruf „get_object_map()“ kann eine Objektzuordnung in einem nichtflüchtigen Speicher lesen, damit GPU-Threads wissen können, wo in dem nichtflüchtigen Speicher jedes Objekt beginnt. Die ausgegebene Zuordnung kann jedem aufgerufenen GPU-Kernel übergeben werden.
Ein API-Aufruf „int pcreate(size_t n_bytes)“ kann ein neues Objekt mit einer Größe von „n_bytes“ Anzahl von Bytes in dem nichtflüchtigen Speicher erstellen und fügt das neue Objekt der Objektzuordnung hinzu. Die Objekt-ID kann ausgegeben werden.
Bei einem „size_t pread(int obj_id, size_t offset, size_t n_bytes, char* buffer)“ kann es sich um einen API-Aufruf handeln, der „n_bytes“ Anzahl von Bytes ab dem angegebenen „offset“ (relative Adresse) in dem Objekt mit der Objekt-ID „obj_id“ in dem nichtflüchtigen Speicher liest und die gelesenen Daten in dem von einem Benutzer bereitgestellten Puffer speichert. Das heißt, die Objekt-ID (z.B. „obj_id“) kann eine eindeutige Kennung für ein Objekt sein. Jedes in dem nichtflüchtigen Speicher gespeicherte Objekt kann eine eindeutige Kennung aufweisen, damit sie beim Verwenden eines allgemeinen API-ähnlichen „pread“ zum Angeben des Objekts verwendet werden kann. Bei der Objekt-ID (z.B. „obj_id“) kann es sich um einen Dateideskriptor oder einen Dateipfad handeln.
Ein API-Aufruf „int pread_prefetch(int obj_id, size_t offset, size_t n_bytes)“ übermittelt die EA-Anfrage für den „pread“ und legt eine Zuordnung zwischen einer E/A-Anfrage und einer NVMe-Befehls-ID fest.
Ein API-Aufruf „size_t consume_prefetch_pread(int ID, char* buffer, size_t n_bytes)“ wartet, bis ein festgelegter Befehl beendet ist, und verwendet das Ergebnis in einem festgelegten Puffer.
Ein API-Aufruf „size_t pwrite(int obj_id, size_t offset, size_t n_bytes, char* buffer)“ kann „n_bytes“ Anzahl von Bytes Anzahl von Bytes, beginnend bei einer relativen Adresse in dem Objekt mit der Objekt-ID „obj_id“ in den nichtflüchtigen Speicher schreiben.
Ein API-Aufruf „flush()“ kann veraltete Einträge in NVMe-Warteschlangen bereinigen und warten, bis alle NVMe-Schreibbefehle abgeschlossen sind.
Nun übergehend zu 8, ist ein Verfahren 800 zum Bereitstellen eines direkten Zugriffs zwischen Beschleunigern (z.B. Grafikverarbeitungseinheiten „GPUs“) und auf einen nichtflüchtigen Speicher in einer Datenverarbeitungsumgebung dargestellt. In einem Aspekt kann jede/jedes/jeder der in den 1 bis 7 beschriebenen Einheiten, Komponenten, Module, Arbeitsschritte und/oder Funktionen auch einen oder mehrere Arbeitsschritte oder Aktionen aus 8 anwenden oder durchführen. Die Funktionalität 800 kann als Verfahren umgesetzt werden, das als Anweisungen auf einer Maschine ausgeführt wird, wobei die Anweisungen auf mindestens einem durch einen Computer lesbaren Medium oder einem nichtflüchtigen, durch eine Maschine lesbaren Speichermedium enthalten sind. Die Funktionalität 800 kann in Block 802 starten.
Einem oder mehreren Beschleunigern kann wie in Block 804 über eine Schnittstelle zur Anwendungsprogrammierung („API“) ein direkter Zugriff auf einen nichtflüchtigen Speicher unabhängig von einer zentralen Host-Verarbeitungseinheit („CPU“) auf einem Steuerpfad oder Datenpfad bereitgestellt werden, um einen Arbeitsschritt des Lesens und einen Arbeitsschritt des Schreibens von Daten durchzuführen. Die Funktionalität 800 kann wie in Block 806 enden.
In einem Aspekt, in Verbindung mit und/oder als Teil mindestens eines Blocks von 8, können die Arbeitsschritte 800 jeweils einen oder mehrere der folgenden Punkte umfassen. Die Arbeitsschritte von 800 können ein(e) oder mehrere nichtflüchtige(s) Express-Speicher- („NVMe“-) Warteschlange(n) und -Register in einem Speicheradressraum des einen oder der mehreren Beschleuniger zuordnen. Die Arbeitsschritte von 800 können einen Seitencache verwenden, der von dem einen oder den mehreren Beschleunigern in dem Speicher des einen oder der mehreren Beschleuniger verwaltet wird, um Lokalität in den Daten zu nutzen, und/oder einen verteilten Seitencache verwenden, der von dem einen oder den mehreren Beschleunigern in dem Speicher einer Mehrzahl von Beschleunigern verwaltet wird, um Lokalität in den Daten zu nutzen.
Die Arbeitsschritte von 800 können eine oder mehrere Seiten aus dem nichtflüchtigen Speicher in einen Seitencache kopieren und eine Seitenzuordnungstabelle aktualisieren. Die Arbeitsschritte von 800 können die Host-CPU beim Kopieren der Daten aus dem nichtflüchtigen Speicher auf den einen oder die mehreren Beschleuniger aus dem Steuerpfad oder Datenpfad entfernen. Die Arbeitsschritte von 800 können die Daten mit der API vorab lesen und Rechenzyklen zum Überlagern der Berechnung und Bewegung der Daten einsparen. Die Arbeitsschritte von 800 können beim Empfangen eines oder mehrerer API-Aufrufe für den Arbeitsschritt des Lesens oder den Arbeitsschritt des Schreibens der Daten, die von dem einen oder den mehreren Beschleunigern eingeleitet wurden, ein Auftreten eines Seitencachefehlers ermitteln, eine oder mehrere Seiten aus einem oder mehreren nichtflüchtigen Express-Speicher- („NVMe“-) Datenpuffern in einen Seitencache kopieren und/oder eine Seitenzuordnungstabelle aktualisieren.
Die Arbeitsschritte von 800 können eine Objektadresse für jedes Objekt in dem nichtflüchtigen Speicher empfangen, wenn eine Anwendung gestartet wird. Eine Zuordnung jeder Objektkennung („ID“), eine Startblockadresse des Objekts und eine Objektgröße können von der Host-CPU verwaltet und in einem reservierten Bereich des nichtflüchtigen Speichers dauerhaft gespeichert werden. Die Arbeitsschritte von 800 können unter Verwendung einer oder mehrerer API-Aufrufe an den einen oder die mehreren Beschleuniger einen Teilbereich von Seiten für jedes Objekt zuweisen.
Bei der vorliegenden Erfindung kann es sich um ein System, ein Verfahren und/oder ein Computerprogrammprodukt handeln. Das Computerprogrammprodukt kann ein durch einen Computer lesbares Speichermedium (oder -medien) mit durch einen Computer lesbaren Programmanweisungen darauf umfassen, um einen Prozessor dazu zu veranlassen, Aspekte der vorliegenden Erfindung auszuführen.
Bei dem durch einen Computer lesbaren Speichermedium kann es sich um eine physische Einheit handeln, die Anweisungen zur Verwendung durch ein System zur Ausführung von Anweisungen behalten und speichern kann. Bei dem durch einen Computer lesbaren Speichermedium kann es sich zum Beispiel um eine elektronische Speichereinheit, eine magnetische Speichereinheit, eine optische Speichereinheit, eine elektromagnetische Speichereinheit, eine Halbleiterspeichereinheit oder jede geeignete Kombination daraus handeln, ohne auf diese beschränkt zu sein. Zu einer nicht erschöpfenden Liste spezifischerer Beispiele des durch einen Computer lesbaren Speichermediums gehören die Folgenden: eine auswechselbare Computerdiskette, eine Festplatte, ein Direktzugriffsspeicher (RAM), ein Nur-Lese-Speicher (ROM), ein löschbarer programmierbarer Nur-Lese-Speicher (EPROM bzw. Flash-Speicher), ein statischer Direktzugriffsspeicher (SRAM), ein auswechselbarer Kompaktspeicherplatte-Nur-Lese-Speicher (CD-ROM), eine DVD (digital versatile disc), ein Speicher-Stick, eine Diskette, eine mechanisch kodierte Einheit wie zum Beispiel Lochkarten oder erhabene Strukturen in einer Rille, auf denen Anweisungen gespeichert sind, und jede geeignete Kombination daraus. Ein durch einen Computer lesbares Speichermedium soll in der Verwendung hierin nicht als flüchtige Signale an sich aufgefasst werden, wie zum Beispiel Funkwellen oder andere sich frei ausbreitende elektromagnetische Wellen, elektromagnetische Wellen, die sich durch einen Wellenleiter oder ein anderes Übertragungsmedium ausbreiten (z.B. Lichtwellenleiterkabel durchlaufende Lichtimpulse) oder durch einen Draht übertragene elektrische Signale.
Hierin beschriebene, durch einen Computer lesbare Programmanweisungen können von einem durch einen Computer lesbaren Speichermedium auf jeweilige Datenverarbeitungs-/Verarbeitungseinheiten oder über ein Netzwerk wie zum Beispiel das Internet, ein lokales Netzwerk, ein Weitverkehrsnetz und/oder ein drahtloses Netzwerk auf einen externen Computer oder eine externe Speichereinheit heruntergeladen werden. Das Netzwerk kann Kupferübertragungskabel, Lichtwellenübertragungsleiter, drahtlose Übertragung, Leitwegrechner, Firewalls, Vermittlungseinheiten, Gateway-Computer und/oder Host-Server umfassen. Eine Netzwerkadapterkarte oder Netzwerkschnittstelle in jeder Datenverarbeitungs-/Verarbeitungseinheit empfängt durch einen Computer lesbare Programmanweisungen aus dem Netzwerk und leitet die durch einen Computer lesbaren Programmanweisungen zur Speicherung in einem durch einen Computer lesbaren Speichermedium innerhalb der entsprechenden Datenverarbeitungs-/Verarbeitungseinheit weiter.
Bei durch einen Computer lesbaren Programmanweisungen zum Ausführen von Arbeitsschritten der vorliegenden Erfindung kann es sich um Assembler-Anweisungen, ISA-Anweisungen (Instruction-Set-Architecture), Maschinenanweisungen, maschinenabhängige Anweisungen, Mikrocode, Firmware-Anweisungen, zustandssetzende Daten oder entweder Quellcode oder Objektcode handeln, die in einer beliebigen Kombination aus einer oder mehreren Programmiersprachen geschrieben werden, darunter objektorientierte Programmiersprachen wie Smalltalk, C++ o.ä. sowie herkömmliche prozedurale Programmiersprachen wie die Programmiersprache „C“ oder ähnliche Programmiersprachen. Die durch einen Computer lesbaren Programmanweisungen können vollständig auf dem Computer des Benutzers, teilweise auf dem Computer des Benutzers, als eigenständiges Software-Paket, teilweise auf dem Computer des Benutzers und teilweise auf einem fernen Computer oder vollständig auf dem fernen Computer oder Server ausgeführt werden. In letzterem Fall kann der entfernt angeordnete Computer mit dem Computer des Benutzers durch eine beliebige Art Netzwerk verbunden sein, darunter ein lokales Netzwerk (LAN) oder ein Weitverkehrsnetz (WAN), oder die Verbindung kann mit einem externen Computer hergestellt werden (zum Beispiel über das Internet unter Verwendung eines Internet-Dienstanbieters). In einigen Ausführungsformen können elektronische Schaltungen, darunter zum Beispiel programmierbare Logikschaltungen, vor Ort programmierbare Gatter-Anordnungen (FPGA, field programmable gate arrays) oder programmierbare Logikanordnungen (PLA, programmable logic arrays) die durch einen Computer lesbaren Programmanweisungen ausführen, indem sie Zustandsinformationen der durch einen Computer lesbaren Programmanweisungen nutzen, um die elektronischen Schaltungen zu personalisieren, um Aspekte der vorliegenden Erfindung durchzuführen.
Aspekte der vorliegenden Erfindung sind hierin unter Bezugnahme auf Ablaufpläne und/oder Blockschaltbilder bzw. Schaubilder von Verfahren, Vorrichtungen (Systemen) und Computerprogrammprodukten gemäß Ausführungsformen der Erfindung beschrieben. Es wird darauf hingewiesen, dass jeder Block der Ablaufpläne und/oder der Blockschaltbilder bzw. Schaubilder sowie Kombinationen von Blöcken in den Ablaufplänen und/oder den Blockschaltbildern bzw. Schaubildern mittels durch einen Computer lesbare Programmanweisungen ausgeführt werden können.
Diese durch einen Computer lesbaren Programmanweisungen können einem Prozessor eines Universalcomputers, eines Spezialcomputers oder einer anderen programmierbaren Datenverarbeitungsvorrichtung bereitgestellt werden, um eine Maschine zu erzeugen, so dass die über den Prozessor des Computers bzw. der anderen programmierbaren Datenverarbeitungsvorrichtung ausgeführten Anweisungen ein Mittel zur Umsetzung der in dem Block bzw. den Blöcken der Ablaufpläne und/oder der Blockschaltbilder bzw. Schaubilder festgelegten Funktionen/Schritte erzeugen. Diese durch einen Computer lesbaren Programmanweisungen können auch auf einem durch einen Computer lesbaren Speichermedium gespeichert sein, das einen Computer, eine programmierbare Datenverarbeitungsvorrichtung und/oder andere Einheiten so steuern kann, dass sie auf eine bestimmte Art funktionieren, so dass das durch einen Computer lesbare Speichermedium, auf dem Anweisungen gespeichert sind, ein Herstellungsprodukt umfasst, darunter Anweisungen, welche Aspekte der/des in dem Block bzw. den Blöcken der Ablaufpläne und/oder der Blockschaltbilder bzw. Schaubilder angegebenen Funktion/Schritts umsetzen.
Die durch einen Computer lesbaren Programmanweisungen können auch auf einen Computer, eine andere programmierbare Datenverarbeitungsvorrichtung oder eine andere Einheit geladen werden, um das Ausführen einer Reihe von Prozessschritten auf dem Computer bzw. der anderen programmierbaren Vorrichtung oder anderen Einheit zu verursachen, um einen auf einem Computer ausgeführten Prozess zu erzeugen, so dass die auf dem Computer, einer anderen programmierbaren Vorrichtung oder einer anderen Einheit ausgeführten Anweisungen die in dem Block bzw. den Blöcken der Ablaufpläne und/oder der Blockschaltbilder bzw. Schaubilder festgelegten Funktionen/Schritte umsetzen.
Die Ablaufpläne und die Blockschaltbilder bzw. Schaubilder in den Figuren veranschaulichen die Architektur, die Funktionalität und den Betrieb möglicher Ausführungen von Systemen, Verfahren und Computerprogrammprodukten gemäß verschiedenen Ausführungsformen der vorliegenden Erfindung. In diesem Zusammenhang kann jeder Block in den Ablaufplänen oder Blockschaltbildern bzw. Schaubildern ein Modul, ein Segment oder einen Teil von Anweisungen darstellen, die eine oder mehrere ausführbare Anweisungen zur Ausführung der bestimmten logischen Funktion(en) umfassen. In einigen alternativen Ausführungen können die in den Blöcken angegebenen Funktionen in einer anderen Reihenfolge als in den Figuren gezeigt stattfinden. Zwei nacheinander gezeigte Blöcke können zum Beispiel in Wirklichkeit im Wesentlichen gleichzeitig ausgeführt werden, oder die Blöcke können manchmal je nach entsprechender Funktionalität in umgekehrter Reihenfolge ausgeführt werden. Es ist darüber hinaus anzumerken, dass jeder Block der Blockschaltbilder bzw. Schaubilder und/oder der Ablaufpläne sowie Kombinationen aus Blöcken in den Blockschaltbildern bzw. Schaubildern und/oder den Ablaufplänen durch spezielle auf Hardware beruhende Systeme umgesetzt werden können, welche die festgelegten Funktionen oder Schritte durchführen, oder Kombinationen aus Spezial-Hardware und Computeranweisungen ausführen.

Claims

Verfahren zum Bereitstellen eines direkten Zugriffs auf einen nichtflüchtigen Speicher in einer Datenverarbeitungsumgebung durch einen Prozessor, aufweisend: Bereitstellen eines direkten Zugriffs auf einen nichtflüchtigen Speicher für einen oder mehrere Beschleuniger über eine Schnittstelle zur Anwendungsprogrammierung „API“, unabhängig von einer zentralen Host-Verarbeitungseinheit „CPU“ auf einem Steuerpfad oder Datenpfad, um einen Arbeitsschritt des Lesens und einen Arbeitsschritt des Schreibens von Daten durchzuführen.
Verfahren nach Anspruch 1, das darüber hinaus ein Zuordnen einer/eines oder mehrerer nichtflüchtiger Express-Speicher- „NVMe“-Warteschlangen und -Register in einem Speicheradressraum des einen oder der mehreren Beschleuniger umfasst.
Verfahren nach Anspruch 1, das darüber hinaus ein Verwenden eines Seitencaches umfasst, der von dem einen oder den mehreren Beschleunigern in dem Speicher des einen oder der mehreren Beschleuniger verwaltet wird, um Lokalität in den Daten zu nutzen.
Verfahren nach Anspruch 1, das darüber hinaus ein Verwenden eines verteilten Seitencaches umfasst, der von dem einen oder den mehreren Beschleunigern in dem Speicher einer Mehrzahl von Beschleunigern verwaltet wird, um Lokalität in den Daten zu nutzen.
Verfahren nach Anspruch 1, darüber hinaus umfassend: Kopieren einer oder mehrerer Seiten aus dem nichtflüchtigen Speicher in einen Seitencache und Aktualisieren einer Seitenzuordnungstabelle; oder Entfernen der Host-CPU aus dem Steuerpfad oder Datenpfad beim Kopieren der Daten aus dem nichtflüchtigen Speicher auf den einen oder die mehreren Beschleuniger.
Verfahren nach Anspruch 1, das darüber hinaus ein Vorablesen der Daten mit der API und ein Einsparen von Rechenzyklen zum Überlagern von Berechnung und Bewegung der Daten umfasst.
Verfahren nach Anspruch 1, darüber hinaus umfassend: Ermitteln eines Auftretens eines Seitencachefehlers beim Empfangen eines oder mehrerer API-Aufrufe für den Arbeitsschritt des Lesens oder den Arbeitsschritt des Schreibens der Daten, die von dem einen oder den mehreren Beschleunigern eingeleitet wurden; Kopieren einer oder mehrerer Seiten aus einem oder mehreren nichtflüchtigen „NVMe“-Datenpuffern in einen Seitencache; und Aktualisieren einer Seitenzuordnungstabelle.
System zum Bereitstellen eines direkten Zugriffs auf einen nichtflüchtigen Speicher, aufweisend: einen oder mehrere Computer mit ausführbaren Anweisungen, die beim Ausführen das System veranlassen zum: Bereitstellen eines direkten Zugriffs auf einen nichtflüchtigen Speicher für einen oder mehrere Beschleuniger über eine Schnittstelle zur Anwendungsprogrammierung „API“, unabhängig von einer zentralen Host-Verarbeitungseinheit „CPU“ auf einem Steuerpfad oder Datenpfad, um einen Arbeitsschritt des Lesens und einen Arbeitsschritt des Schreibens von Daten durchzuführen.
System nach Anspruch 8, wobei die ausführbaren Anweisungen eine/ein oder mehrere nichtflüchtige Speicher-Express-„NVMe“-Warteschlangen und -Register in einem Speicheradressraum des einen oder der mehreren Beschleuniger zuordnen.
System nach Anspruch 8, wobei die ausführbaren Anweisungen einen Seitencache verwenden, der von dem einen oder den mehreren Beschleunigern in dem Speicher des einen oder der mehreren Beschleuniger verwaltet wird, um Lokalität in den Daten zu nutzen.
System nach Anspruch 8, wobei die ausführbaren Anweisungen einen verteilten Seitencache verwenden, der von dem einen oder den mehreren Beschleunigern in dem Speicher einer Mehrzahl von Beschleunigern verwaltet wird, um Lokalität in den Daten zu nutzen.
System nach Anspruch 8, wobei die ausführbaren Anweisungen: eine oder mehrere Seiten aus dem nichtflüchtigen Speicher in einen Seitencache kopieren und eine Seitenzuordnungstabelle aktualisieren; oder die Host-CPU aus dem Steuerpfad oder Datenpfad beim Kopieren der Daten aus dem nichtflüchtigen Speicher auf den einen oder die mehreren Beschleuniger entfernen.
System nach Anspruch 8, wobei die ausführbaren Anweisungen die Daten mit der API vorab lesen und jeden Rechenzyklus zum Überlagern von Berechnung und Bewegung der Daten speichern.
System nach Anspruch 8, wobei die ausführbaren Anweisungen: ein Auftreten eines Seitencachefehlers beim Empfangen eines oder mehrerer API-Aufrufe für den Arbeitsschritt des Lesens oder den Arbeitsschritt des Schreibens der Daten, die von dem einen oder den mehreren Beschleunigern eingeleitet wurden, ermitteln; eine oder mehrere Seiten aus einem oder mehreren nichtflüchtigen „NVMe“-Datenpuffern in einen Seitencache kopieren; und eine Seitenzuordnungstabelle aktualisieren.
Computerprogrammprodukt zum Bereitstellen eines direkten Zugriffs auf einen nichtflüchtigen Speicher durch einen Prozessor, wobei das Computerprogrammprodukt ein nichtflüchtiges, durch einen Computer lesbares Speichermedium aufweist, auf dem durch einen Computer lesbare Programmcodeteile gespeichert sind, die durch einen Computer lesbaren Programmcodeteile aufweisend: einen ausführbaren Teil, der über eine Schnittstelle zur Anwendungsprogrammierung „API“ einen direkten Zugriff auf einen nichtflüchtigen Speicher für einen oder mehrere Beschleuniger bereitstellt, unabhängig von einer zentralen Host-Verarbeitungseinheit „CPU“ auf einem Steuerpfad oder Datenpfad, um einen Arbeitsschritt des Lesens und einen Arbeitsschritt des Schreibens von Daten durchzuführen.
Computerprogrammprodukt nach Anspruch 15, darüber hinaus umfassend einen ausführbaren Teil, der eine/ein oder mehrere nichtflüchtige Speicher-Express-„NVMe“-Warteschlangen und -Register in einem Speicheradressraum des einen oder der mehreren Beschleuniger zuordnet.
Computerprogrammprodukt nach Anspruch 15, darüber hinaus umfassend einen ausführbaren Teil, der: einen Seitencache verwendet, der von dem einen oder den mehreren Beschleunigern in dem Speicher des einen oder der mehreren Beschleuniger verwaltet wird, um Lokalität in den Daten zu nutzen; oder einen verteilten Seitencache verwendet, der von dem einen oder den mehreren Beschleunigern in dem Speicher einer Mehrzahl von Beschleunigern verwaltet wird, um Lokalität in den Daten zu nutzen.
Computerprogrammprodukt nach Anspruch 15, darüber hinaus umfassend einen ausführbaren Teil, der: eine oder mehrere Seiten aus dem nichtflüchtigen Speicher in einen Seitencache kopiert und eine Seitenzuordnungstabelle aktualisiert; oder die Host-CPU aus dem Steuerpfad oder Datenpfad beim Kopieren der Daten aus dem nichtflüchtigen Speicher auf den einen oder die mehreren Beschleuniger entfernt.
Computerprogrammprodukt nach Anspruch 15, darüber hinaus umfassend einen ausführbaren Teil, der die Daten mit der API vorab liest und jeden Rechenzyklus zum Überlagern von Berechnung und Bewegung der Daten speichert.
Computerprogrammprodukt nach Anspruch 15, darüber hinaus umfassend einen ausführbaren Teil, der: ein Auftreten eines Seitencachefehlers beim Empfangen eines oder mehrerer API-Aufrufe für den Arbeitsschritt des Lesens oder den Arbeitsschritt des Schreibens der Daten, die von dem einen oder den mehreren Beschleunigern eingeleitet wurden, ermittelt; eine oder mehrere Seiten aus einem oder mehreren nichtflüchtigen „NVMe“-Datenpuffern in einen Seitencache kopiert; und eine Seitenzuordnungstabelle aktualisiert.