DE102021127151A1 - Verfahren und system für libfabric atomics-basierte lockless cluster-wide shared memory access api in einem verteilten system - Google Patents

Verfahren und system für libfabric atomics-basierte lockless cluster-wide shared memory access api in einem verteilten system Download PDF

Info

Publication number
DE102021127151A1
DE102021127151A1 DE102021127151.7A DE102021127151A DE102021127151A1 DE 102021127151 A1 DE102021127151 A1 DE 102021127151A1 DE 102021127151 A DE102021127151 A DE 102021127151A DE 102021127151 A1 DE102021127151 A1 DE 102021127151A1
Authority
DE
Germany
Prior art keywords
remote memory
shared
offset
bits
semaphore
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
DE102021127151.7A
Other languages
English (en)
Inventor
Oleg Neverovitch
Yann Livis
Dmitry Ivanov
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Hewlett Packard Enterprise Development LP
Original Assignee
Hewlett Packard Enterprise Development LP
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Hewlett Packard Enterprise Development LP filed Critical Hewlett Packard Enterprise Development LP
Publication of DE102021127151A1 publication Critical patent/DE102021127151A1/de
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F15/00—Digital computers in general; Data processing equipment in general
    • G06F15/16—Combinations of two or more digital computers each having at least an arithmetic unit, a program unit and a register, e.g. for a simultaneous processing of several programs
    • G06F15/163—Interprocessor communication
    • G06F15/173—Interprocessor communication using an interconnection network, e.g. matrix, shuffle, pyramid, star, snowflake
    • G06F15/17306—Intercommunication techniques
    • G06F15/17331—Distributed shared memory [DSM], e.g. remote direct memory access [RDMA]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10—File systems; File servers
    • G06F16/18—File system types
    • G06F16/182—Distributed file systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0628—Interfaces specially adapted for storage systems making use of a particular technique
    • G06F3/0655—Vertical data movement, i.e. input-output transfer; data movement between one or more hosts and one or more storage devices
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F13/14—Handling requests for interconnection or transfer
    • G06F13/20—Handling requests for interconnection or transfer for access to input/output bus
    • G06F13/28—Handling requests for interconnection or transfer for access to input/output bus using burst mode transfer, e.g. direct memory access DMA, cycle steal
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0602—Interfaces specially adapted for storage systems specifically adapted to achieve a particular effect
    • G06F3/0604—Improving or facilitating administration, e.g. storage management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0628—Interfaces specially adapted for storage systems making use of a particular technique
    • G06F3/0655—Vertical data movement, i.e. input-output transfer; data movement between one or more hosts and one or more storage devices
    • G06F3/0659—Command handling arrangements, e.g. command buffers, queues, command scheduling
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0668—Interfaces specially adapted for storage systems adopting a particular infrastructure
    • G06F3/067—Distributed or networked storage systems, e.g. storage area networks [SAN], network attached storage [NAS]
    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B2219/00—Program-control systems
    • G05B2219/30—Nc systems
    • G05B2219/36—Nc in input of data, input key till input tape
    • G05B2219/36037—Application programming interface associates component code with driver function

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Human Computer Interaction (AREA)
  • Computer Hardware Design (AREA)
  • Data Mining & Analysis (AREA)
  • Databases & Information Systems (AREA)
  • Mathematical Physics (AREA)
  • Software Systems (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

Das System weist in einem verteilten System, das eine Vielzahl von Knoten umfasst, eine Vielzahl von Speicherabschnitten zu, die einen gemeinsam genutzten entfernten Speicherinhalt umfassen. Das System registriert die zugewiesenen Teile bei einem Betriebssystem für den Zugriff über RDMA. Das System greift über einen ersten Knoten auf die zugewiesenen Teile zu, um eine lokale Kopie zu erhalten. Das System führt eine atomare Operation an einem oder mehreren Bits des gemeinsam genutzten entfernten Speicherinhalts über libfabric atomic application programming interface-Aufrufe aus, indem es eines oder mehrere der folgenden Verfahren durchführt: Aktualisieren des einen oder der mehreren Bits auf der Grundlage eines neuen Werts und eines Offsets; Abrufen eines aktuellen Werts des einen oder der mehreren Bits aus dem gemeinsam genutzten entfernten Speicherinhalt auf der Grundlage des Offsets vor dem Aktualisieren; und Durchführen einer Aktion an dem gemeinsam genutzten entfernten Speicherinhalt auf der Grundlage eines Vergleichs des abgerufenen aktuellen Werts mit einem erwarteten Wert in der lokalen Kopie.

Description

  • HINTERGRUND
  • Feld
  • Diese Offenbarung bezieht sich allgemein auf den Bereich der Verwaltung. Genauer gesagt bezieht sich diese Offenlegung auf ein Verfahren und ein System für libfabric atomics-basierte sperrfreie clusterweite gemeinsame Speicherzugriffs-API in einem verteilten System.
  • Figurenliste
    • zeigt ein Diagramm einer beispielhaften Umgebung zur Erleichterung eines libfabric atomics (LFA)-basierten gemeinsamen Speicherzugriffs gemäß einem Aspekt der vorliegenden Anwendung.
    • zeigt ein Diagramm einer beispielhaften Umgebung zur Erleichterung eines LFA-basierten gemeinsamen Speicherzugriffs, einschließlich einer gemeinsamen Bitmap, gemäß einem Aspekt der vorliegenden Anwendung.
    • zeigt ein Diagramm eines Inhaltsverzeichnisses, eines Zählerfeldes und beispielhafter Kommunikationen, die mit dem Zugriff auf Dateien in einem Dateisystem verbunden sind, in Übereinstimmung mit einem Aspekt der vorliegenden Anwendung.
    • zeigt eine beispielhafte Umgebung zur Erleichterung der Verwendung einer gemeinsam genutzten Ringpuffer-Warteschlange zur Übermittlung von Nachrichten unter Verwendung eines LFA-basierten gemeinsamen Speicherzugriffs in einem verteilten System gemäß einem Aspekt der vorliegenden Anwendung.
    • zeigt ein Flussdiagramm, das ein Verfahren veranschaulicht, das einen LFA-basierten gemeinsamen Speicherzugriff in einem verteilten System in Übereinstimmung mit einem Aspekt der vorliegenden Anwendung ermöglicht.
    • zeigt ein Flussdiagramm, das ein Verfahren veranschaulicht, das einen LFA-basierten gemeinsamen Speicherzugriff in einem verteilten System in Übereinstimmung mit einem Aspekt der vorliegenden Anwendung ermöglicht.
    • zeigt ein Flussdiagramm, das ein Verfahren veranschaulicht, das den Zugriff auf Dateien in einem Dateisystem unter Verwendung eines LFA-basierten gemeinsamen Speicherzugriffs in einem verteilten System in Übereinstimmung mit einem Aspekt der vorliegenden Anwendung erleichtert.
    • zeigt ein Flussdiagramm, das ein Verfahren veranschaulicht, das die Zustellung von Nachrichten über eine gemeinsame Ringpuffer-Warteschlange unter Verwendung eines LFA-basierten gemeinsamen Speicherzugriffs in einem verteilten System gemäß einem Aspekt der vorliegenden Anwendung erleichtert.
    • zeigt ein Flussdiagramm, das ein Verfahren veranschaulicht, das die Zustellung von Nachrichten über eine gemeinsame Ringpuffer-Warteschlange unter Verwendung eines LFA-basierten gemeinsamen Speicherzugriffs in einem verteilten System gemäß einem Aspekt der vorliegenden Anwendung erleichtert.
    • zeigt ein beispielhaftes Computersystem, das einen LFA-basierten gemeinsamen Speicherzugriff gemäß einem Aspekt der vorliegenden Anwendung ermöglicht.
    • zeigt eine beispielhafte Vorrichtung, die einen LFA-basierten gemeinsamen Speicherzugriff gemäß einem Aspekt der vorliegenden Anwendung ermöglicht.
  • In den Abbildungen beziehen sich gleiche Ziffern auf die gleichen Elemente der Abbildung.
  • AUSFÜHRLICHE BESCHREIBUNG
  • Die folgende Beschreibung soll den Fachmann in die Lage versetzen, die Aspekte und Beispiele herzustellen und zu verwenden, und wird im Zusammenhang mit einer bestimmten Anwendung und deren Anforderungen gegeben. Verschiedene Modifikationen der offengelegten Aspekte sind für den Fachmann leicht erkennbar, und die hierin definierten allgemeinen Grundsätze können auf andere Aspekte und Anwendungen angewandt werden, ohne vom Geist und Umfang der vorliegenden Offenbarung abzuweichen. Daher sind die hier beschriebenen Aspekte nicht auf die gezeigten Aspekte beschränkt, sondern haben den größtmöglichen Umfang, der mit den hier offengelegten Grundsätzen und Merkmalen vereinbar ist.
  • Eine entscheidende Aufgabe in einem verteilten System oder Cluster mit mehreren Komponenten auf mehreren Geräten (z. B. Hochleistungs-Cluster (HPC)-Anwendungen in groß angelegten Cluster-Rechenumgebungen) ist die Synchronisierung des Zugriffs auf clusterweit gemeinsam genutzte Variablen und Datenstrukturen. Bei der Implementierung einer gemeinsamen Programmierschnittstelle (API) für den Datenzugriff sollte ein Gleichgewicht zwischen der Gewährleistung der Kohärenz über alle Knoten hinweg und einer möglichst geringen zusätzlichen Latenz beim Zugriff auf eine gemeinsame Entität für eine Lese-, Schreib- oder Aktualisierungsoperation gefunden werden.
  • Einige aktuelle Cluster-Synchronisierungsmethoden beinhalten einen verteilten Sperrmanager (DLM) und verwenden ein nachrichtenbasiertes System, z. B. zwischen einem Client und einem Server. Mit zunehmender Anzahl von Knoten (z. B. in einem HPC) kann jedoch die erhöhte Latenz (durch Senden, Empfangen, Verarbeiten und Reagieren auf Nachrichten, einschließlich Abrufen und Freigeben von Sperren) zunehmend untragbar werden. Auch die Skalierbarkeit kann ein Problem darstellen. Eine erhöhte Last auf einem abhörenden Server kann zusammen mit einer Erhöhung des Umfangs des Systems zu einem Engpass führen. Andere Methoden können eine gemeinsame Nachrichtenwarteschlange verwenden, aber die Leistung solcher Systeme kann aufgrund der Komplexität der Implementierung und des unvermeidlichen bidirektionalen Datenverkehrs begrenzt sein.
  • Die hier beschriebenen Aspekte bieten ein System, das diese Herausforderungen angeht, indem es clusterweite sperrfreie atomare Operationen unter Verwendung von libfabric atomics (LFA)-Operationen auf gemeinsam genutzten Speicherbereichen bereitstellt. In einem verteilten System oder Cluster mit vielen Knoten kann jeder Knoten auf gemeinsam genutzte Daten zugreifen, ohne Sperren zu erwerben, indem er einfach seine lokale Kopie eines gemeinsam genutzten Objekts verwendet, um das Ergebnis einer gewünschten Aktualisierung vorherzusagen und die Kohärenz der gewünschten Aktualisierung mit einer Compare-and-Swap-(CAS)-Libfabric-Operation sicherzustellen. Das System kann die Zieladresse der Aktualisierung algorithmisch auf die entfernten Speicher mehrerer Knoten verteilen, wodurch die Kollisionsrate unter Kontrolle gehalten werden kann. Dadurch können sowohl die Latenzzeit bei der Durchführung von Operationen als auch die Beanspruchung gemeinsam genutzter Ressourcen verringert werden. Das beschriebene System kann zur Implementierung verschiedener Arten von gemeinsam genutzten Objekten verwendet werden, z. B. Zähler, Bitmaps, strukturierte Daten und clusterweite Synchronisationsprimitive wie Spinlocks, Semaphoren und Ringpuffer-Warteschlangen.
  • Gemeinsame atomare Daten
  • In einem verteilten System, z. B. einem Cluster-Dateisystem wie dem Fabric Attached Memory Filesystem (FAMfs), besteht eine wichtige Aufgabe darin, bestimmte wichtige Datenstrukturen im Speicher zu halten und diese Datenstrukturen auf allen Knoten, die das Dateisystem aktiv nutzen, gemeinsam zu nutzen. Eine Lösung besteht darin, alle Dateisystem-Metadaten in einer gemeinsamen kohärenten Datenbank zu speichern. Mit zunehmender Anzahl der Knoten (wie in einem HPC) kann die Leistung einer solchen gemeinsamen kohärenten Datenbank jedoch exponentiell abnehmen. Bei den hier beschriebenen Aspekten werden die Metadaten nach wie vor in einer Datenbank verwaltet und beim Start in den Speicher geladen, wo sie anschließend über libfabric atomics (LFA) API-Aufrufe bearbeitet werden. Die Datenstrukturen, auf die durch diese LFA-API-Aufrufe zugegriffen wird, bleiben möglicherweise nur so lange relevant, wie die FAMfs aktiv ist. Die Datenstrukturen können bei jedem Neustart aus der Datenbank neu aufgebaut werden. Darüber hinaus kann das System alle relevanten Aktualisierungen der Datenbank mit Hilfe der FAMfs-Software im Hintergrund durchführen, so dass die Aktualisierungen den Zugriff auf die gemeinsamen Metadaten in den Datenstrukturen über die LFA-API-Aufrufe nicht beeinträchtigen. Da sich die Datenbank nie im Pfad der LFA-Operationen befindet, kommt es zu keiner zusätzlichen Latenzzeit.
  • Bei der Verwendung von LFA-Aufrufen können die Einheiten vom logischen Standpunkt aus ähnlich wie bei einem Client-Server-Modell bezeichnet werden, obwohl es keine Server im traditionellen Sinne des Client-Server-Modells gibt. In den hier beschriebenen Aspekten kann ein „Server“ oder „Serverknoten“ einfach einen bestimmten Bereich oder Teil („blob‟) seines eigenen Speichers als gemeinsam genutztes Objekt (das eine beliebige Struktur haben kann) deklarieren oder zuweisen. Der Serverknoten kann die zugewiesenen Teile beim Betriebssystem registrieren, wodurch das Betriebssystem darüber informiert wird, dass der zugewiesene Bereich im Speicher gesperrt werden muss. Der Server-Knoten kann auch Zugriffsschlüssel für die „Clients“ oder „Client-Knoten“ erstellen. Damit ist die Verantwortung des Servers beendet. Der Rest der Operationen kann von den „Clients“ durchgeführt werden, wie unten in Bezug auf beschrieben. Es ist zu beachten, dass diese Clients und Server derselbe Knoten/Prozess oder verschiedene Knoten/Prozesse sein können.
  • Das System kann mit den gemeinsam genutzten Objekten der zugewiesenen BLOBs als einem einzigen zusammenhängenden Raum arbeiten, der aus allen zugewiesenen BLOBs besteht. Dieser einzelne zusammenhängende Raum kann als „LFA-Bereich“ oder „gemeinsamer entfernter Speicherinhalt“ bezeichnet werden. Das beschriebene System kann mehrere LFA-Bereiche umfassen, die alle unabhängig voneinander sind, d. h. LFA-Blobs, die von verschiedenen Gruppen von Serverknoten in einem verteilten System zugewiesen werden. Die Größe jedes von einem Server zugewiesenen Blobs kann unterschiedlich sein, d. h. sie kann nicht dieselbe Größe wie die anderen Blobs in einem bestimmten LFA-Bereich haben.
  • Um auf gemeinsam genutzte Daten in einem bestimmten LFA-Bereich zugreifen zu können, muss sich ein Knoten über einen LFA-API-Aufruf an den LFA-Bereich anschließen, wodurch die erforderlichen libfabric-Verbindungen zu allen Servern des gegebenen LFA-Bereichs hergestellt werden. Die LFA-API-Aufrufe können mit globalen Offsets innerhalb des gegebenen LFA-Bereichs arbeiten. Unter Verwendung eines bestimmten Offsets kann die LFA-API den gewünschten Ort im entfernten Speicher berechnen, d. h. die libfabric-Adresse innerhalb des Servers, der einen Teil seines Speichers als globalen Raum sowie einen lokalen Offset innerhalb des gegebenen LFA-Bereichs abbildet. Das System kann die Auflösung der Serveradresse auf der Grundlage einer schnellen binären Suche in einem geordneten Array der registrierten LFA-Blobs erreichen.
  • Die Kohärenz von libfabric-Atomoperationen kann nur durch die Verwendung von libfabric-Aufrufen gewährleistet werden. Folglich müssen alle Aktualisierungen von Inhalten im LFA-Bereich über libfabric-Aufrufe erfolgen. So kann ein Client beispielsweise nur über einen LFA-API-Aufruf auf den LFA-Bereich zugreifen, selbst wenn sich ein Zielobjekt oder ein Speicherplatz im Speicher desselben Clients befindet oder dort liegt.
  • Ein Zielobjekt ist ein gemeinsam genutztes Objekt, das ein 32-Bit-Wort oder ein 64-Bit-Wort mit einem bestimmten globalen Offset innerhalb eines LFA-Bereichs sein kann. Das System kann verschiedene Operationen sowohl für 32-Bit- als auch für 64-Bit-Wörter unterstützen. Bulk-Get/Put-Operationen können das Laden bzw. Speichern von entferntem Speicher in den bzw. aus dem lokalen Puffer ermöglichen. Diese Operationen garantieren keine Kohärenz und sollten nur verwendet werden, wenn Gleichzeitigkeit kein Thema ist, z. B. beim Start, wenn das System die LFA-Bereiche aus der Datenbank auffüllt.
  • Das System kann einfache arithmetische Operationen (z. B. Addieren und Subtrahieren eines Wertes von einem entfernten Ort) sowie logische bitweise Operationen (z. B. logische UND-, ODER- und Exklusiv-ODER (XOR)-Operationen) unterstützen. Darüber hinaus kann das System Vergleichsoperationen unterstützen, bei denen das System einen abgerufenen entfernten Wert mit einem lokalen Wert vergleichen und den entfernten Wert durch einen neuen Wert ersetzen kann, wenn es feststellt, dass der abgerufene entfernte Wert mit dem lokalen Wert übereinstimmt. Die arithmetischen und bitweisen Operationen können die „do-and-fetch“-Variante unterstützen. Außerdem können die atomaren Operationen oder Befehle in Hardware implementiert werden.
  • Da jeder Client seine eigene vollständige lokale Kopie des gemeinsam genutzten entfernten Speicherinhalts verwaltet, kann jeder Client seine lokale Kopie auf normale programmatische Weise durchsuchen, ohne etwas sperren zu müssen. Bei einer Aktualisierung des gemeinsam genutzten entfernten Speicherinhalts kann der Client einen LFA-API-Aufruf tätigen, um sicherzustellen, dass die Aktualisierung gültig und kohärent ist (z. B. durch einen „Do-and-Fetch“-Vorgang). Kommt es zu einer Kollision (d. h., wenn mehr als ein Knoten versucht hat, dasselbe Wort im entfernten Speicher gleichzeitig zu aktualisieren), liegt es in der Verantwortung des Clients, diese Kollision zu beheben. In der Praxis kann in einer hochparallelen verteilten Umgebung die Wahrscheinlichkeit einer Kollision gering sein, was das Konzept unterstreicht, dass es in manchen Fällen einfacher oder effizienter sein kann, um Vergebung zu bitten als um Erlaubnis.
  • zeigt ein Diagramm einer beispielhaften Umgebung 100 zur Erleichterung gemeinsam genutzter atomarer Daten, in Übereinstimmung mit einem Aspekt der vorliegenden Anwendung. Die Umgebung 100 kann Folgendes umfassen: mehrere „Server“-Knoten, z. B. einen Server-Knoten_0 138, einen Server-Knoten_1 148 und einen Server-Knoten_N 158; und mehrere Client-Knoten, z. B. einen Client-Knoten_0 110 und einen Client-Knoten_M 120 („Client-Knoten 110 und 120“).
  • Jeder Serverknoten kann einen „Blob“ seines lokalen Speichers zuweisen und den zugewiesenen Blob beim Betriebssystem registrieren, damit über direkten Fernspeicherzugriff (RDMA) darauf zugegriffen werden kann. Zum Beispiel kann der Serverknoten_0 138 einen LFA-Blob_0 130, der Serverknoten_1 148 einen LFA-Blob_1 140 und der Serverknoten_N 158 einen LFA-Blob_N 150 zuweisen. Jeder Blob kann eine Vielzahl von Bits, Sätzen von einem oder mehreren Bits oder Wörtern enthalten. Zum Beispiel kann LFA blob_0 130 mindestens enthalten: ein Wort W[0] 132; ein Wort W[1] 134; und ein Wort W[2] 136. In ähnlicher Weise kann LFA blob_1 140 mindestens ein Wort W[i] 142 und LFA blob_N 150 mindestens ein Wort W[n] 152 enthalten. Das System kann somit einen „LFA-Bereich“ oder „gemeinsamen entfernten Speicherinhalt“ erstellen, der diese zugewiesenen LFA-Blobs (130, 140 und 150) enthält.
  • Jeder Client kann sich anschließend mit dem LFA-Bereich verbinden, um seine eigene lokale Kopie des gemeinsam genutzten entfernten Speicherinhalts zu erhalten. Beispielsweise kann jeder der Client-Knoten 110 und 120 eine Verbindung zum LFA-Bereich herstellen, der aus den LFA-Blobs 130, 140 und 150 besteht, um seine eigene lokale Kopie des gemeinsamen entfernten Speicherinhalts zu erhalten (z. B. eine lokale Kopie 111 für Client-Knoten_1 110 und eine lokale Kopie 121 für Client-Knoten_M 120). Die Client-Knoten 110 und 120 können den gemeinsamen entfernten Speicherinhalt im LFA-Bereich mit einem 1fa_get()-Aufruf in ihre jeweiligen lokalen Puffer laden und mit der Arbeit an der erhaltenen lokalen Kopie in ihren Puffern beginnen.
  • Die lokale Kopie 111 kann mindestens Folgendes enthalten: ein Wort W[0] 112; ein Wort W[1] 114; ein Wort W[i] 116; und ein Wort W[n] 118. Die lokale Kopie 121 kann mindestens Folgendes enthalten: ein Wort W[0] 122; ein Wort W[1] 124; ein Wort W[i] 126; und ein Wort W[n] 128. Die Wörter in jeder der lokalen Kopien können den Wörtern in jedem der LFA-Blobs 130, 140 und 150 entsprechen. Zum Beispiel: Das Wort W[0] 122 in der lokalen Kopie 121 kann dem Wort W[0] 132 des LFA-Blob 130 entsprechen (und kann im LFA-Bereich über eine Kommunikation 160 aufgerufen/aktualisiert werden); das Wort W[i] 126 in der lokalen Kopie 121 kann dem Wort W[i] 142 des LFA-Blob 140 entsprechen (und kann über eine Kommunikation 162 aufgerufen/aktualisiert werden); und das Wort W[n] 128 in der lokalen Kopie 121 kann dem Wort W[n] 152 des LFA-Blob 150 entsprechen (und kann über eine Kommunikation 164 aufgerufen/aktualisiert werden).
  • Wenn ein Client-Knoten ein bestimmtes Wort innerhalb des LFA-Bereichs aktualisieren möchte, kann das System einen LFA-API-Aufruf (z. B. eine libfabric-Operation) auf der Grundlage eines neuen Werts für das bestimmte Wort und eines globalen Offsets für das bestimmte Wort innerhalb des LFA-Bereichs ausgeben, z. B. indem es den neuen Wert und den globalen Offset als Argumente für den LFA-API-Aufruf verwendet. Das System kann einen Zielserver bestimmen, der mit dem LFA-Blob verbunden ist, in dem das bestimmte Wort gespeichert ist, unter Verwendung eines lokalen Offsets innerhalb des entfernten Speichers des Zielservers, und kann anschließend die atomare Libfabric-Operation an dem bestimmten Wort durchführen (z. B. eine „gewünschte Aktion“ durch Ersetzen eines aktuellen Wertes durch einen neuen Wert).
  • Handelt es sich bei dem LFA-API-Aufruf um einen „Do-and-Fetch“-Vorgang, kann der LFA-API-Aufruf alternativ den aktuellen Wert des betreffenden Worts im entfernten Speicher des Zielservers abrufen, bevor die gewünschte Aktion für das betreffende Wort durchgeführt wird. Um zu überprüfen, dass keine Kollision auftritt, kann das System den abgerufenen aktuellen Wert im entfernten Speicher mit dem erwarteten Wert in der lokalen Kopie (z. B. einem „lokalen aktuellen Wert“) vergleichen. Stimmt der abgefragte aktuelle Wert nicht mit dem erwarteten Wert überein, kann der Client eine geeignete Maßnahme ergreifen, z. B. um die Kollision aufzulösen.
  • Gemeinsame Bitmap
  • Bitmaps sind bekannte Strukturen, die in Dateisystemen und anderen Anwendungen, die freien/verwendeten Speicher oder Speicherplatz verfolgen, ausgiebig genutzt werden. Bitmaps können als ein lokales Speicherfeld implementiert werden, in dem ein einzelnes Bit einem Datenblock entspricht. Ein Wert des Bits gleich „1“ zeigt an, dass der Block verwendet wird. Ist der Wert des Bits gleich „0“, bedeutet dies, dass der Block frei ist. Operationen mit Bits können effizient sein, da moderne CPUs verschiedene Bitmanipulationsbefehle in Hardware implementieren können. Die Manipulation eines einzelnen Bits in einer Bitmap, die von mehreren Knoten in einem verteilten System (z. B. einem HPC-Cluster) gemeinsam genutzt wird, kann jedoch eine Herausforderung darstellen.
  • In einem Fabric Attached Memory Filesystem (FAMfs) kann das System LFA-API-Aufrufe verwenden, um eine gemeinsame Bitmap zu implementieren, die die Nutzung von Medien-„Extents“ in einer „Extent-Bitmap“ verfolgt. „Der FAM-Adressraum kann in einer Reihe von Chunks organisiert werden, während ein FAM-Modul in „Extents“ zugewiesen werden kann. Ein Extent kann eine minimale Einheit der FAM-Zuweisung eines einzelnen FAM-Moduls sein. FAMfs kann Extents (die von verschiedenen FAM-Modulen zugewiesen werden) in „Slabs“ organisieren, um die Implementierung eines bestimmten Datenschutzschemas (das auf Dateiebene festgelegt werden kann) zu erleichtern. Ein Slab kann als Container für „Stripes“ verwendet werden (z.B. indem er als Container für die Zuweisung von Stripes dient). Stripes sind Sammlungen von Datenblöcken mit demselben Schutzniveau wie der jeweilige Container-Slab. Eine „Slab-Map“ ist eine Datenstruktur, die die Geometrie und den Aufbau eines Layouts beschreiben kann, d. h. welche FAM-Extents zusammengesetzt werden, um einen entsprechenden Slab zu bilden und ein bestimmtes Schutzschema zu unterstützen. Eine „Extent-Bitmap“ ist eine Datenstruktur, die festhält, ob ein bestimmter Extent (auf einem FAM-Modul oder auf der Ebene des nichtflüchtigen Speichers (NVMe)) verwendet wird oder frei ist.
  • Sowohl die Slab-Map als auch die Extent-Bitmap können in FAMfs gemeinsame Datenstrukturen sein. In FAMfs kann das System die Extent-Bitmaps als globales Bitmap-Array mit LFA-basierten clusterweiten Datenstrukturen implementieren. Diese Extent-Bitmaps können die Speicherplatzzuweisung über alle FAM-Module hinweg unterstützen, ohne dass clusterweite Sperren erforderlich sind. Dieses globale Bitmap-Array kann auf alle Knoten verteilt werden, die die FAM-Extents im Namen der Benutzerprozesse von FAMfs zuweisen.
  • Bestimmte Knoten im FAMfs können LFA-API-Aufrufe auf der Extent-Bitmap-Datenstruktur aufrufen. Beispielsweise können Ein-/Ausgabeknoten in FAMfs ein Zuweisungsmodul enthalten, das seinen spezifischen gemeinsamen Speicherbereich (für eine Slab-Map oder eine Extent-Bitmap) zuweist. Diese E/A-Knoten können als „Allokationsknoten“ bezeichnet werden. Jeder Zuordnungsknoten kann auch seine eigene lokale Kopie der vollständigen Bitmap verwalten, wie unten in Bezug auf beschrieben. Das heißt, jeder Zuordnungsknoten kann für seinen eigenen Teil des FAM-Pools verantwortlich sein, wodurch die Lokalität der Algorithmen, die die Zuordnung vornehmen, gewährleistet werden kann. Das Produkt der Zuweisung - eine Bitmap der zugewiesenen FAM-Extents, die den Status „belegt/frei“ anzeigt - kann jedoch eine globale Einheit sein, die von allen beteiligten Knoten (z. B. E/A-Knoten oder Zuweisungsknoten in FAMfs) gemeinsam genutzt wird. Dies kann dazu führen, dass die Konsistenz der Informationen in Bezug auf die Zuweisung zwischen allen teilnehmenden Knoten gewährleistet ist. Im Gegensatz dazu wäre das Sperren der gesamten Karte für jede Zuweisung unerschwinglich kostspielig. Die derzeitige Lösung bietet daher eine effiziente Möglichkeit, ein gemeinsames globales Bitmap-Array für mehrere Zuweisungsknoten in einem verteilten Dateisystem (z. B. FAMfs) zu ermöglichen.
  • In FAMfs wird eine Extent-Bitmap pro FAM-Modul verwendet, und Extent-Bitmaps werden nur zwischen Allokationsknoten und jedem Knoten, der auf die Extent-Maps für alle FAM-Module im FAMfs-Pool zugreifen muss, gemeinsam genutzt. Infolgedessen erstellt ein (jeder) Server ein LFA-Blob für den Teil der globalen Extent-Map, für den der jeweilige Server zuständig ist, und weist es zu. Gleichzeitig verbindet sich der jeweilige Server mit jedem LFA-Blob im LFA-Bereich, einschließlich seines eigenen zugewiesenen LFA-Blob. Wie hier beschrieben, führt das System alle LFA-Operationen über LFA-API-Aufrufe durch, um die Kohärenz auf der CPU-Cache-Ebene zu gewährleisten, auch wenn der jeweilige Server auf Daten zugreifen möchte, die in seinem eigenen zugewiesenen LFA-Blob gespeichert sind. In FAMfs bestimmt das System die Partitionierung der LFA-Ausdehnungskarte auf der Grundlage des LFA-API-Aufrufers (z. B. des FAMfs Dynamic Space Allocator).
  • zeigt ein Diagramm einer beispielhaften Umgebung 200 zur Erleichterung gemeinsam genutzter atomarer Daten, einschließlich einer gemeinsam genutzten Bitmap, in Übereinstimmung mit einem Aspekt der vorliegenden Anwendung. Die Umgebung 200 kann eine Vielzahl von Knoten umfassen: einen Zuordnungsknoten 0 210; einen Zuordnungsknoten_1 220; und einen Zuordnungsknoten_N 230. Jeder Zuordnungsknoten kann sein eigenes „Blob“ oder „Bitmap-Segment“ zuordnen. Alle zugewiesenen BLOBs oder Bitmap-Segmente können virtuell oder logisch zusammengesetzt werden, um den LFA-Bereich zu bilden. Außerdem kann jeder Zuweisungsknoten seine eigene lokale Kopie aller im LFA-Bereich enthaltenen Bitmap-Segmente erhalten.
  • Zum Beispiel: Zuweiser node_0 210 kann ein Bitmap-Segment_0 212 zuweisen, das eine Vielzahl von Bits enthalten kann; Zuweiser node_1 220 kann ein Bitmap-Segment_1 222 zuweisen, das eine Vielzahl von Bits enthalten kann; und Zuweiser node_N 230 kann ein Bitmap-Segment_N 232 zuweisen, das eine Vielzahl von Bits enthalten kann. Die Bits in diesen zugewiesenen Bitmap-Segmenten können durch die leeren quadratischen Felder angezeigt werden. Ein LFA-Bereich 240 kann eine virtuelle Bitmap darstellen, die alle Bitmap-Segmente (z. B. 212, 222 und 232) enthält, die von den Zuweisungsknoten (z. B. 210, 220 und 230) zugewiesen wurden.
  • Der Zuweiser node_0 210 kann eine lokale vollständige Bitmap-Kopie 214 erhalten, indem er sich an die virtuelle Bitmap 240 anhängt (z. B. wie durch die Pfeile 266 und 274 angezeigt), die wiederum an jedes der Bitmap-Segmente 212, 222 und 232 angehängt wird (z. B. wie durch die Pfeile 252 und 254 für das Bitmap-Segment 0 212, die Pfeile 256 und 260 für das Bitmap-Segment_1 222 und die Pfeile 262 und 264 für das Bitmap-Segment_2 232 angezeigt). In ähnlicher Weise kann der Zuweiser node_1 220 eine lokale vollständige Bitmap-Kopie 224 erhalten, indem er sich an die zugewiesenen Bitmap-Segmente in ähnlicher Weise anhängt (z. B. wie durch die Pfeile 270 und 276 angezeigt). Der Zuweiser node_2 230 kann ebenfalls eine lokale vollständige Bitmap-Kopie 234 erhalten, indem er sich an die zugewiesenen Bitmap-Segmente anhängt (z. B. wie durch die Pfeile 272 und 278 angezeigt).
  • Die LFA-API-Aufrufe für die Ausdehnungs-Bitmap können eine globale Find-first-clear-bit-and-set-Methode implementieren, die die globale Bitmap durchläuft, um das erste klare Bit zu suchen, beginnend mit einer bestimmten Anfangsposition. Diese Anfangsposition kann durch einen Algorithmus bestimmt werden, der darauf abzielt, die Konkurrenz unter den Anforderern zu verringern, d. h. der versucht, die Bits zu verteilen. Da der anfordernde Prozess immer eine lokale Kopie der gesamten Bitmap in seinem lokalen Puffer hat, kann das System über eingebaute CPU-Befehle (z. B. durch Invertierung des Wertes und anschließende Durchführung einer ffs()-Operation in x86) effizient zuerst den lokalen Puffer durchsuchen. Das ideale Ergebnis ist, dass das Bit an der Anfangsposition frei ist. Wenn das Bit an der Anfangsposition jedoch nicht frei ist, kann die ffs()-Anweisung die nächste verfügbare Position zurückgeben. Die API kann anschließend einen atomaren logischen ODER- und Abruf-Aufruf von libfabric ausführen, der versucht, den neuen Wert in den globalen gemeinsamen Speicher zu übertragen.
  • Wenn das Bit an der entsprechenden globalen Speicherstelle gelöscht ist, wird der Vorgang erfolgreich abgeschlossen. Ist das Bit an der entsprechenden globalen Speicherstelle nicht gelöscht, was darauf hinweist, dass das Bit von einem anderen Akteur oder einer anderen Einheit gesetzt wurde, kann der LFA-Aufruf sowohl einen Fehlercode als auch den Inhalt des globalen Speichers zurückgeben, der unmittelbar vor dem Versuch, das Bit zu setzen oder zu übertragen, abgerufen wurde. Dies liefert eine aktuelle Momentaufnahme des aktuellen Werts der Bitmap, die es dem System ermöglicht, auf der Grundlage dieser Informationen eine intelligente Entscheidung zu treffen. Das System kann über den Algorithmus im Allgemeinen versuchen, innerhalb des lokalen Bereichs zu bleiben, z. B. auf demselben Knoten, der durch den von einer Hash-Funktion berechneten Anfangswert bestimmt wird. Dies kann zu einer Verringerung des E/A-Verkehrs in der Fabric führen und auch zu einer Verringerung der Gleichzeitigkeit beitragen. Das System kann erst dann in den LFA-Bereich eines anderen Knotens wechseln, wenn es feststellt, dass alle Bits in seinem „lokalen“ LFA-Bereich gesetzt sind.
  • Beachten Sie, dass der „Fetch“-Teil des LFA-API-Aufrufs immer ausgeführt werden kann. Somit kann das System selbst bei einem erfolgreichen ersten Versuch, ein Bit zu setzen, den aktualisierten Inhalt oder aktuellen Wert des globalen Speichers zurückgeben, einschließlich aller Bits, die möglicherweise durch andere Operationen gesetzt wurden. Aus der Sicht jedes Zuweisungsknotens kann die Ausdehnungsbitmap eine Art selbstheilende lokale Kopie des gemeinsam genutzten globalen Speichers darstellen.
  • Clusterweite Spinlocks und Semaphoren
  • Die LFA-API-Aufrufe können zwar einen sperrfreien Zugriff auf gemeinsam genutzte Daten ermöglichen (wie oben beschrieben), sind aber im Allgemeinen auf den Betrieb mit separaten Speicherwörtern beschränkt. In einigen Fällen muss das System möglicherweise einen konsistenten transaktionalen Zugriff auf mehrere Felder gleichzeitig gewährleisten, z. B. wenn eine bestimmte Datenstruktur durchlaufen und anschließend erweitert oder aktualisiert werden muss, wobei die Konsistenz über mehr als ein Datenwort hinweg gewahrt bleiben muss. Da LFA-API-Aufrufe im Allgemeinen nur innerhalb der Grenzen eines Wortes kohärent sind, muss das System den Zugriff auf die gesamte Struktur auf andere Weise regeln.
  • Die hier beschriebenen Aspekte regeln den Zugriff auf die gesamte Datenstruktur durch die Implementierung eines globalen Spinlocks. Ein Spinlock kann in den Kemeln moderner Betriebssysteme verwendet werden, um die Synchronisierung zwischen mehreren Threads zu ermöglichen. In den beschriebenen Aspekten kann das System einen globalen, clusterweiten Spinlock auf der Grundlage von LFA-API-Aufrufen erstellen. Wenn ein aufrufender Prozess den Spinlock erwerben muss, kann der Prozess einen LFA-CAS-Aufruf (Compare-and-Swap) in einen der vordefinierten LFA-Bereiche absetzen, die Sperren für verschiedene Zwecke enthalten. Der CAS-Aufruf kann einen entfernten Ort auf einen bestimmten Wert setzen, aber nur, wenn der entfernte Ort einen Anfangswert enthält, der mit einem erwarteten Wert übereinstimmt (z. B. wenn der abgerufene aktuelle entfernte Wert mit einem lokalen aktuellen Wert übereinstimmt). Stimmt der abgefragte Wert mit dem erwarteten Wert überein, ist der Vorgang erfolgreich. Der aufrufende Prozess kann den Spinlock erwerben und nach Bedarf fortfahren.
  • Stimmt der abgefragte Wert nicht mit dem erwarteten Wert überein, bedeutet dies, dass ein anderer Prozess den Spinlock bereits erworben hat und an den durch den Spinlock geschützten Daten arbeitet. Der aufrufende Prozess ruft daraufhin erneut das CAS auf und setzt die Schleife fort, bis entweder der Spinlock erfolgreich erworben wurde oder eine Timeout-Periode abläuft. Wenn der aufrufende Prozess (oder jeder andere Prozess, der den Spinlock erwirbt) mit der Aktualisierung der Daten im kritischen Abschnitt fertig ist, kann dieser Prozess den Spinlock durch einen einfachen LFA-Schreibaufruf freigeben, der den Wert des entfernten Spinlocks auf den entsperrten Zustand zurücksetzen kann.
  • Ähnlich wie das globale, clusterweite Spinlock können LFA-API-Aufrufe ein clusterweites Zählsemaphor implementieren, das den Zugriff auf zählbare Ressourcen erleichtert. Anstelle des CAS-Aufrufs kann die Semaphor-API atomare Add-and-Fetch- und Decrement-and-Fetch-Aufrufe verwenden. Wenn ein neues freies Objekt in einem durch den Semaphor geschützten Pool entdeckt wird, kann das System den Wert des Semaphors atomar um eins erhöhen. Wenn ein Client oder eine andere Einheit ein Objekt in dem durch die Semaphore geschützten Pool erwerben muss, kann der Client versuchen, die Semaphore um eins zu dekrementieren. Wenn der Wert der Semaphore (nach dem Dekrementierungsversuch) größer als Null ist, kann der Vorgang fortgesetzt werden. Ist der Wert der Semaphore (nach dem Dekrementierungsversuch) nicht größer als Null, was bedeutet, dass die Semaphore zum Zeitpunkt des Aufrufs bereits auf Null stand, kann der Client den Versuch, das Objekt zu erwerben, zu einem späteren Zeitpunkt wiederholen.
  • Sowohl die globale Spinlock- als auch die globale Semaphore-Implementierung basieren auf dem hier beschriebenen LFA-Bereich, und beide Synchronisationsprimitive können die LFA-Infrastruktur nutzen. Beispielsweise kann das System diese beiden Synchronisationsprimitive entweder in einem speziellen LFA-Bereich getrennt von anderen gemeinsam genutzten Daten oder als Teil globaler Strukturen aufbewahren, die sowohl die Sperre als auch die geschützte Datenstruktur enthalten, wie nachstehend in Bezug auf beschrieben.
  • Inhaltsverzeichnis und Zähler Array
  • In großen Systemen, wie HPC-Anwendungen und verteilten Systemen oder Clustern, besteht eine wichtige Aufgabe darin, die Nutzung von Ressourcen sowohl für statistische Leistungsanalysen als auch für die tatsächliche Ressourcenplanung und -verteilung zu verfolgen. Dies kann eine schwierige Aufgabe sein, da der Zugriff auf diese Ressourcen bei HPC-Anwendungen in großem Umfang gleichzeitig erfolgen kann. Die obige Beschreibung bezieht sich auf die Implementierung atomarer Zähler unter Verwendung der LFA-API, aber die Zuweisung dieser Zähler kann in einem System, in dem Tausende von Knoten gleichzeitig Hunderte von Dateien erstellen, eine schwierige Aufgabe sein.
  • Ein Aspekt des beschriebenen Systems bietet einen einfachen und zuverlässigen Mechanismus für die Zuweisung verschiedener Nutzungszähler innerhalb eines Clusters. Das System bietet ein Inhaltsverzeichnis (Table of Contents, TOC), in dem alle vorhandenen Zähler aufgeführt sind. Außerdem weist das System einen Speicherblock zu, der die Zähler selbst enthält. Das System kann die TOC und den Zählerblock (oder Blob) auf die gleiche Weise partitionieren wie einen regulären LFA-Bereich, um den Datenverkehr der Fabric über mehrere Serverknoten zu verteilen. Das System kann jede TOC-Partition mit einem globalen Spinlock schützen.
  • Im Beispiel von FAMfs hat jede Datei eine eindeutige Kennung („FileID“), wie unten beschrieben. Ein Client kann eine TOC-Suche nach einer bestimmten Dateikennung in einer bestimmten LFA durchführen, indem er zunächst in seiner lokalen Kopie der TOC sucht, ohne den globalen Spinlock zu erwerben, entsprechend dem allgemeinen Prinzip der LFA. Wenn die gegebene FileID in der lokalen Kopie des TOC gefunden wird, besteht eine hohe Wahrscheinlichkeit, dass die Datei bereits an der entsprechenden globalen Speicherstelle gespeichert ist. Der Client kann dann den Spinlock auf der TOC-Partition, die zu der angegebenen LFA gehört, erwerben und dies überprüfen. Wenn die Datei bereits von einem anderen Prozess entsorgt wurde und der globale TOC-Eintrag leer ist oder eine andere FileID enthält, kann das System einen vollständigen Scan des TOCs durchführen und einen neuen TOC-Eintrag zuweisen. Wenn die angegebene FileID in der lokalen Kopie des TOC nicht gefunden wird, kann das System auf der Grundlage einer algorithmischen Entscheidung den globalen Spinlock auf der TOC-Partition, die zu der angegebenen LFA gehört, erwerben. Das System kann anschließend in den Einträgen des TOC nach der FileID suchen, um z. B. einen leeren Eintrag oder einen Eintrag mit der gegebenen FileID zu finden, wenn dieser bereits von einem anderen Client-Prozess vergeben wurde. Ähnlich dem allgemeinen Prinzip des LFA-Designs sind alle zählerbezogenen Operationen einseitig, d.h. es findet kein Nachrichtenaustausch zwischen Clients und Servern statt. Alle Operationen sind atomare RDMA-Transaktionen vom Client zum Speicher des Serverknotens.
  • In FAMfs muss das Dateisystem sowohl die offenen Dateien als auch die Aktualisierungen dieser offenen Dateien verfolgen. FAMfs ist ein prüfpunkt- und wiederherstellungsorientiertes Dateisystem und muss daher auch verfolgen, wann Dateien „laminiert“ sind, d. h. wann die Berechnung des Löschcodes (EC) für eine Datei abgeschlossen ist und die Datei vor System-, Geräte- oder FAM-Modulausfällen geschützt ist. Da der EC-Codierungsprozess jedoch nicht an Dateien, sondern an physischen Datenblöcken in den FAM-Modulen durchgeführt wird, bieten die hier beschriebenen Aspekte eine alternative Möglichkeit, den Laminierungsfortschritt zu verfolgen. Eine Lösung besteht darin, einfach eine vordefinierte Anzahl von Zählern zuzuweisen. Dies kann jedoch entweder verschwenderisch sein, wenn zu viele Zähler zugewiesen werden, oder äußerst ineffizient, wenn ein Client-Prozess darauf warten muss, dass ein Zähler verfügbar wird.
  • In FAMfs hat jede Datei eine eindeutige Kennung („FileID“), die aus dem vollqualifizierten Namen der Datei abgeleitet wird. Diese FileID kann verwendet werden, um alle mit der Datei verbundenen Zähler zu verfolgen, z. B.: Anzahl der geöffneten Dateien, Anzahl der Schreibvorgänge usw. Wenn das System einen open _file()-Aufruf tätigt, sucht der Client-Prozess zunächst nach der FileID (z. B. „X“) im TOC in einem bestimmten LFA-Bereich. Der TOC-LFA-Bereich kann von allen Serverknoten gemeinsam genutzt werden (wie oben in Bezug auf beschrieben) und kann durch ein globales Spinlock geschützt werden (wie unten in Bezug auf beschrieben). Ähnlich wie bei den allgemeinen LFA-Prinzipien zielt das System darauf ab, die Last algorithmisch so weit wie möglich zu verteilen. Das System kann die Dateikennung als Eingabe für eine Hash-Funktion verwenden, mit der die Last gleichmäßig auf alle Knoten verteilt werden kann, die einen bestimmten LFA-Bereich bedienen. Die Hash-Funktion kann eine hohe Wahrscheinlichkeit dafür bieten, dass mehrere open_file()-Aufrufe desselben Client-Knotens an verschiedene Server-Knoten gerichtet werden, was dazu führen kann, dass alle E/A-Knoten im Cluster gleichmäßig belastet werden. So kann die Hash-Funktion auf der Grundlage der eindeutigen FileID der Datei feststellen, dass ein bestimmter Server für eine bestimmte Datei zuständig ist. Das System kann den Dateinamen in seine eindeutige FileID übersetzen, die auf einen bestimmten LFA-Bereich verweist, ähnlich wie bei den oben in Bezug auf beschriebenen Ausdehnungsbitmaps.
  • zeigt ein Diagramm 300 eines Inhaltsverzeichnisses 320, eines Zählerfeldes 340 und beispielhafter Kommunikationen, die mit dem Zugriff auf Dateien in einem Dateisystem verbunden sind, in Übereinstimmung mit einem Aspekt der vorliegenden Anwendung. Diagramm 300 kann einen Anforderer_1 310 (z. B. einen Client-Prozess), ein Inhaltsverzeichnis (TOC) 320 und ein Zähler-Array 340 enthalten. Anforderer_1 310 kann eine Reihe von Schritten (311-315) durchführen, um auf eine bestimmte Datei zuzugreifen. Das Inhaltsverzeichnis 320 kann einen zugehörigen Spinlock (SL) 322 und Einträge enthalten, die mindestens Folgendes angeben: eine Datei-ID 324 für eine bestimmte Datei (z. B. die FileID); eine Referenzzahl 326, die angeben kann, wie viele Clients die bestimmte Datei derzeit geöffnet haben; und einen Offset 328, der ein Offset im Zähler-Array 340 sein kann. Das Zähler-Array 340 kann ein Array sein, das zur Verwaltung der Zähler für eine bestimmte FileID zugewiesen wird. Ein Eintrag 330 in TOC 320 kann eine FileID von „0“, einen Referenzzähler von „0“ und einen Offset von „0“ enthalten, was einen leeren Eintrag anzeigen kann. Ein Eintrag 332 in TOC 320 kann eine FileID von „X“, einen Referenzzählwert von „RC_X“ und einen Offset von „OFF_X“ enthalten. In ähnlicher Weise kann ein Eintrag 334 in TOC 320 eine FileID von „Y“, eine Referenzanzahl von „RC_Y“ und einen Offset von „OFF_Y“ enthalten. Die Referenzanzahl und der Offset können ganzzahlige Werte sein.
  • Wenn das System durch einen Client-Prozess eine Datei mit einer FileID = „X“ öffnen möchte, kann der Client-Prozess zunächst die TOC berechnen, zu der diese FileID gehört, z. B. durch Verwendung der Hash-Funktion. Wie oben beschrieben, kann der Client zunächst eine Suche nach der FileID in seiner lokalen Kopie des TOC durchführen, ohne den globalen Spinlock zu aktivieren. Wenn die FileID in der lokalen TOC nicht existiert, kann der Client-Prozess feststellen, dass die TOC 320 einer bestimmten LFA (nicht gezeigt) die geeignete TOC ist. Der Client-Prozess kann den Spinlock 322 für TOC 320 erwerben (wie durch eine step_1 311 und eine acquire 350 Kommunikation angezeigt). Der Client-Prozess kann TOC 320 nach der FileID von „X“ scannen (wie durch einen Schritt_2312 und eine scan 352-Kommunikation angezeigt). Der Scanvorgang kann bei Eintrag 330 beginnen. Findet der Client-Prozess die FileID von „X“ (d. h. einen übereinstimmenden Eintrag 332), kann das System die Referenzanzahl erhöhen (wie durch eine step_3 313 und eine increment reference count 354-Kommunikation angezeigt). Wenn der Client-Prozess die FileID von „X“ nicht findet (z. B. wenn der Eintrag 332 in TOC 320 nicht existiert), kann das System einen Eintrag für die FileID von „X“ erstellen, den Referenzzähler um eins erhöhen, alle anderen relevanten Zähler initialisieren und im neuen TOC-Eintrag einen ausgewählten Offset im Zähler-Array 340 aufzeichnen (z. B. durch Verwendung eines ersten verfügbaren oder einer anderen Art der Bestimmung eines Elements im Zähler-Array 340, in dem der aktuelle Wert des Zählers selbst verfolgt wird).
  • Anschließend kann der Client-Prozess den Spinlock 322 freigeben (wie durch eine step_4 314- und eine release 356-Kommunikation angezeigt), wodurch TOC 320 für alle anderen anfordernden Client-Prozesse, Knoten oder Entitäten verfügbar wird. An diesem Punkt kann der Client-Prozess nun direkt auf den Zähler im Zähler-Array zugreifen und ihn bearbeiten. Beispielsweise kann der Client-Prozess den entsprechenden Zähler im Zähler-Array 340 inkrementieren (wie durch eine step_5 315- und eine increment counter 358-Kommunikation angezeigt). Der Client-Prozess kann die Position des entsprechenden Zählers im Zähler-Array 340 bestimmen, indem er den Offset 328 des passenden Eintrags 332 verwendet (wie durch einen gestrichelten Pfeil 362 vom Eintrag 332 zu einem als „Zähler[j]“ bezeichneten Element 346 im Zähler-Array 340 angezeigt).
  • Auf diese Weise kann der Client-Prozess, sobald die Datei geöffnet ist, mit Hilfe eines oder mehrerer Zähler feststellen, wie viele Schreibvorgänge stattgefunden haben (ein erstes Zähler-Array) und wie viele Schreibvorgänge übertragen wurden (ein zweites Zähler-Array). Das System ist nicht auf ein oder zwei Zähler-Arrays beschränkt, sondern kann so viele oder so wenige wie nötig verwenden. Das System kann darauf warten, dass ein Paritäts-Thread die Parität für eine bestimmte Anzahl von Blöcken, die einer Datei entsprechen, berechnet. Wenn die Paritätsberechnung für alle diese Blöcke abgeschlossen ist, kann das System feststellen, dass die Datei für die Laminierung bereit ist.
  • Das System kann häufig auf diese Zähler zugreifen, da die Verarbeitung von Datenblöcken den Zugriff auf die entsprechenden Zähler und deren Inkrementierung zur Folge haben kann. Die Verwendung von LFA-API-Aufrufen und die Aufteilung dieser TOCs und Zähler-Arrays in separate LFA-Bereiche kann dazu führen, dass die Konkurrenz um die Zähler minimiert wird. Die Latenzzeit, die mit der Durchführung der Schritte 311-314 (in ) verbunden ist, muss nur einmal, beim Öffnen der Datei, auftreten. Sobald der Client-Prozess den Offset bestimmt hat, kann er direkt auf den Zähler zugreifen, ohne ihn weiter zu sperren, d. h. er kann nur LFA-API-Aufrufe in einer sperrfreien, clusterweiten Weise verwenden. Diese kurze Verzögerung beim Öffnen/Schließen einer Datei beeinträchtigt die Leistung nicht nennenswert, da das System parallel zur TOC-Suche viele andere Vorgänge durchführt, die diese zusätzliche Latenzzeit verbergen oder überdecken können.
  • Wenn das System durch den Client-Prozess die geöffnete Datei schließen möchte, ruft das System erneut SL 322 auf, sucht den Eintrag für die angeforderte FileID und verringert den Referenzzähler um eins. Ist der Referenzzähler „0“, was bedeutet, dass keine anderen Entitäten, Prozesse oder Knoten im Cluster die Datei geöffnet haben, kann das System den entsprechenden Offset im Eintrag und das zugehörige Element oder den Block im Zähler-Array 340 löschen. Das System kann die entsprechenden Aktualisierungen durchführen und anschließend den Spinlock 322 freigeben.
  • Daher muss ein Client-Prozess den tatsächlichen physischen Standort eines Zählers für eine bestimmte Datei nicht kennen. Mit Hilfe der oben beschriebenen Schritte und Operationen kann der Client-Prozess einfach die relevanten Informationen in einem bestimmten TOC nachschlagen und wie oben beschrieben vorgehen.
  • Globale Ringpuffer-Warteschlange
  • Während die oben beschriebenen Aspekte auf atomare Operationen auf bestimmte entfernte gemeinsame Speicherinhalte abzielen (durch Eliminierung des Message-Passing), müssen die Knoten in einem HPC-Cluster immer noch Message-Passing durchführen (z. B. durch Verwendung von Message-Queues), da dies eine grundlegende Aufgabe in jeder verteilten Anwendung ist. Im Allgemeinen sind Implementierungen von Nachrichtenwarteschlangen relativ komplex und erfordern eine erhebliche Menge an Ressourcen. Die beschriebenen Aspekte des Systems verwenden einen vereinfachten Mechanismus, um eine gemeinsame Warteschlange bereitzustellen, die kurze Nachrichten fester Größe schnell und ressourcenschonend von Knoten zu Knoten weiterleiten kann.
  • Das System basiert auf der oben beschriebenen einseitigen Kommunikation für LFA-API-Aufrufe und -Operationen und verwendet eine Ring Buffer Queue (RBQ). Die RBQ ist eine verteilte Struktur, die als „Segmente“ unter einer Vielzahl von Servern aufgeteilt ist, ähnlich wie die Bitmap des Umfangs oder die in LFA-Blobs enthaltenen Daten, aus denen ein LFA-Bereich besteht. Jedes RBQ-Segment kann Folgendes enthalten: einen Speicherblock, der die zu übertragenden Nachrichten enthält; zwei Semaphoren zur Synchronisierung des Zugriffs; und zwei Zeiger/Zähler zur Verfolgung der Positionen von Einfüge- und Entnahmevorgängen, wie nachstehend in Bezug auf beschrieben.
  • Logischerweise kann ein einziger gemeinsam genutzter RBQ eine Vielzahl von Partitionen oder Segmenten umfassen, die jeweils von einem separaten Serverknoten bedient werden, ähnlich wie jeder LFA-Blob von einem separaten Serverknoten bedient wird. Die Einzelheiten dieser Implementierung sind für die Clients nicht sichtbar. Ein Client kann sich einfach per Name an eine Warteschlange anschließen. Die RBQ kann eine API enthalten, die automatisch die Weiterleitung einer eingehenden Anfrage übernimmt.
  • Jeder Server in einem verteilten System (z. B. jeder E/A- oder Zuweisungsknoten in FAMfs) kann ein Segment für eine bestimmte Warteschlange erstellen und auch den RBQ-Bereich pflegen, der alle erforderlichen Komponenten für das erstellte Segment enthält oder mit diesem verbunden ist. Das System kann die Größe der RBQ beim Starten festlegen. Das System kann über den jeweiligen Serverknoten auch alle erforderlichen Komponenten bei der Erstellung des Segments oder der Warteschlange initialisieren. Das System kann mehrere Warteschlangen erstellen, und jeder Knoten kann sowohl ein Server für eine RBQ als auch ein Client für eine andere sein. Clients können sich an bestehende Warteschlangen anschließen, was dazu führen kann, dass der Zähler für die atomare Nutzung auf dem Server erhöht wird, um die Gesamtnutzung der Warteschlange zu verfolgen und unerwartetes Verhalten beim Verlassen der Warteschlange zu verhindern.
  • zeigt eine beispielhafte Umgebung 400 zur Erleichterung der Verwendung einer gemeinsam genutzten Ringpuffer-Warteschlange zur Übermittlung von Nachrichten gemäß einem Aspekt der vorliegenden Anwendung. Die Umgebung 400 kann eine Vielzahl von Clients (z. B. Clients C0-CN) und eine Vielzahl von Servern umfassen, darunter: einen Server_0410; einen Server_1420; und einen Server_K430. Jeder Server kann ein RBQ-Segment erstellen, das eine Warteschlange umfassen, enthalten, einschließen oder eine Warteschlange sein kann. Zum Beispiel: Server_0410 kann ein RBQ-Segment_0412 erstellen; Server_1420 kann ein RBQ-Segment_1422 erstellen; und Server_K430 kann ein RBQ-Segment_K432 erstellen.
  • Clients können sich an die RBQ-Segmente anschließen, um eine lokale Kopie des RBQ zu erhalten, ähnlich wie Clients sich an jedes LFA-Blob- oder Extent-Bitmap-Segment anschließen können, um die jeweiligen lokalen Kopien zu erhalten (wie oben in Bezug auf die und beschrieben). Zum Beispiel: Client C3 kann sich an RBQ segment_0412 anschließen; Client C7 kann sich an RBQ segment_1422 anschließen; und Client CN kann sich an RBQ segment _K 432 anschließen.
  • Die untere Hälfte von zeigt eine detaillierte Ansicht der Kommunikation zwischen Client CN 450 und Server_K430. Client CN 450 kann ein RBQ-Push-Modul 452 enthalten, das den Zugriff auf ein bestimmtes RBQ-Segment bearbeitet, und Server_K 430 kann ein RBQ-Pop-Modul 440 enthalten, das den Zugriff auf das bestimmte RBQ-Segment bearbeitet. RBQ-Push 452 und RBQ-Pop 440 können ein Modul, ein Prozess, eine Komponente oder eine Einheit sein, die in Middleware, Software oder Hardware implementiert ist.
  • Server_K430 kann auch ein RBQ-Segment_K 432 enthalten, das Folgendes umfassen kann: einen Speicherblock 433 (z. B., einen Speicherblock 433 (z. B. ein Array 433 oder eine Warteschlange 433), der Daten/Nachrichten enthalten kann, die in Elementen wie W[0] 434, W[1] 436 und W[2] 438 übertragen werden; einen Eingangssemaphor (IS) 462 und einen Ausgangssemaphor (OS) 464, um den Zugriff auf die Warteschlange 433 zu synchronisieren; und einen Eingangszeiger (IP) 460 und einen Ausgangszeiger (OP) 466, um Positionen für das Einfügen und Entfernen von Nachrichten aus der Warteschlange 433 zu verfolgen.
  • Bei der Durchführung der Initialisierung und anderer Startvorgänge kann das System IS 462 auf die maximale Größe der Warteschlange 433 setzen. Das System kann OS 464 auf „0“ setzen, um anzuzeigen, dass in der Warteschlange 433 keine Daten (z. B. Nachrichten) gespeichert sind. Das System kann auch sowohl IP 460 als auch OP 466 als Anfangswerte auf „0“ setzen.
  • Während des Betriebs kann ein Client (z. B. Client CN 450), der eine Nachricht in die Ringpuffer-Warteschlange (z. B. Warteschlange 433) stellen möchte, zunächst versuchen, IS 462 zu erhalten. Der Wert von IS 462 kann die Anzahl der freien Slots in der Warteschlange angeben. Wenn der Wert von IS 462 größer als „0“ ist, kann der Client CN 450 IS 462 erwerben, indem er den Wert von IS 462 um „1“ dekrementiert (wie durch einen Schritt 471 (IS--) angezeigt). Ist der Wert von IS 462 „0“ (was bedeutet, dass keine freien oder verfügbaren Slots im RBQ oder in der Warteschlange 433 vorhanden sind), muss der Client warten, bis der Server die Bearbeitung einer Anforderung abgeschlossen hat und IS 462 freigibt. Das Warten auf die Verfügbarkeit eines Semaphors wird im Folgenden beschrieben.
  • Nach erfolgreicher Erfassung von IS 462 kann der Client IP 460 inkrementieren (wie durch Schritt 472 (IP++) angezeigt), so dass IP 460 statt auf W[1] 436 (wie durch einen gestrichelten gebogenen Pfeil 477 angezeigt) nun auf W[2] 438 (wie durch einen fetten gebogenen Pfeil 476 angezeigt) zeigt. Da es sich beim RBQ um einen Ringpuffer handelt, kann das System IP 460 bei Erreichen des Endes des Puffers (d. h. der Warteschlange 433) wieder auf „0“ setzen. Der Client CN 450 kann Daten (z. B. eine Nachricht) über RDMA an den Speicherplatz senden, auf den IP 460 verweist (wie in Schritt 473 angegeben). Es sei daran erinnert, dass jede Nachricht im RBQ-Segment_K 432 die gleiche feste Größe hat. Daher kann das System die Position dieses Speichers (entsprechend W[2] 438) durch eine einfache offsetbasierte Berechnung ermitteln. Schließlich kann der Client CN 450 OS 464 freigeben, indem er den Wert von OS 464 um „1‟ inkrementiert (wie in Schritt 474 (OS++) angegeben). Durch diese Inkrementierung kann Server_K 430 mitgeteilt werden, dass sich Daten in der Warteschlange 433 befinden, die verarbeitet werden können.
  • Im Normalbetrieb kann der Server_K430 auf OS 464 warten, das den Wert „0“ hat, wenn die Warteschlange 433 leer ist. Wenn OS 464 vom Client CN 450 inkrementiert wird (als Teil von Schritt 474), kann Server_K430 OS 464 übernehmen, indem er den Wert von OS 464 um „1“ dekrementiert (wie durch Schritt 481 (OS--) angezeigt). Server_K 430 kann über RDMA die Nachricht abrufen, die an dem Ort gespeichert ist, auf den OP 466 (d. h. W[2] 438) verweist (wie in Schritt 482 angegeben). Nach dem Abrufen der Nachricht oder der Daten aus der Warteschlange 433 kann Server_K 430 OP 466 um „1“ erhöhen (wie in Schritt 483 (OP++) angegeben), so dass OP 466 statt auf W[2] 438 (wie durch einen durchgezogenen gebogenen Pfeil 486 angegeben) nun auf das nächste Element in der Warteschlange 433 zeigt (wie durch einen gestrichelten gebogenen Pfeil 487 angegeben). Ähnlich wie IP 460 für Client CN 450 funktioniert, kann OP 466 zum Anfang des kreisförmigen RBQ-Segments zurückkehren, wenn OP 466 das Ende der Warteschlange 433 erreicht. Um das Festhalten wertvoller Ressourcen zu vermeiden, kann Server_K430 Daten aus dem globalen Speicher in seinen lokalen Puffer (nicht dargestellt) kopieren und anschließend IS 462 freigeben, indem er den Wert von IS 462 um „1“ erhöht (wie durch einen Schritt 484 (IS++) angezeigt), was dazu führt, dass ein freier Slot verfügbar geworden ist. Es ist zu beachten, dass zwar die Steuerinformationen jeder Warteschlange (z. B. IP 460, OP 466, IS 462 und OS 464) in den LFA-Bereichen gespeichert werden können, die Datensegmente jeder Warteschlange jedoch nicht in den LFA-Bereichen gespeichert werden müssen. Die Datensegmente können nur auf dem „Server“-Knoten vorhanden sein, d. h. für den Prozess, dem ein bestimmtes Warteschlangensegment gehört. Wenn der IP/OP-Zustand, wie oben beschrieben, durch atomare Transaktionen bestimmt wird, kann der Client einen regulären RDMA-Lese-/Schreibzugriff von/auf ein entsprechendes Datensegment durchführen, das durch diese Zeiger definiert ist. Der Client muss also keine lokale Kopie der gesamten Warteschlange aufbewahren, da die Atomarität von RDMA durch die Warteschlangen-Semaphore in LFA gewährleistet ist.
  • Das Warten auf die Verfügbarkeit einer Semaphore kann auf unterschiedliche Weise implementiert werden. Eine erste Implementierung für einen Prozess, der eine Semaphore erwerben möchte, besteht darin, einfach einen atomaren CAS-Aufruf weiterzuleiten, bis sich der Wert ändert. Die Wartezeit, die mit dieser Spin-Zeit verbunden ist, ist lokalisiert. Das heißt, obwohl das System während der Wartezeit lokale CPU-Zyklen verschwendet, erzeugt die Spin-Zeit keinen Verkehr in der Fabric, da sich der zu prüfende Wert im Speicher desselben Knotens befindet. Dennoch werden auch bei dieser Methode CPU-Zyklen verbraucht.
  • Eine zweite Implementierung besteht darin, reguläre Nachrichten zwischen dem Client und dem Server zu verwenden, z. B. um eine Benachrichtigung oder eine Wake-up-Nachricht an den Server zu senden, nachdem ein Client ein Element in eine zuvor leere Warteschlange eingefügt hat. Bei dieser Implementierung kann der Server in den Ruhezustand gehen und auf eine Wecknachricht warten, sobald seine Warteschlange erschöpft ist. Diese Lösung führt zwar zu einer anfänglichen Latenzzeit beim Aufwachen, kann aber den Ressourcenverbrauch während des Leerlaufs des Systems verringern. In einem Szenario mit vielen Nachrichten wird der Server nicht in den Ruhezustand versetzt, es werden keine Wecknachrichten übermittelt, und das System kann schnell arbeiten. Allerdings ist diese Implementierung immer noch mit einer anfänglichen Latenzzeit beim Aufwachen verbunden. Das System kann diese anfängliche Latenzzeit ausgleichen, indem es dem Server nur dann eine Wecknachricht sendet, wenn sich eine bestimmte oder vorgegebene Anzahl von Nachrichten in der Warteschlange befindet, anstatt jedes Mal eine Wecknachricht zu senden, wenn die Größe der Warteschlange „1“ (oder eine andere Zahl, die kleiner als die vorgegebene Zahl ist) erreicht.
  • Eine dritte Implementierung ist die Verwendung von libfabric-RDMA-Zählern, um das Aufwachen des Servers zu erleichtern. Einige libfabric-Anbieter ermöglichen die Verwendung von „passiven“ RDMA-Zählern, bei denen ein Zähler seinen Wert ändern kann, wenn auf einen bestimmten Speicherbereich zugegriffen wird (z. B. Schreiben oder Lesen). Eine solche Implementierung kann separate Zähler für Lese- und Schreibvorgänge unterstützen. Wenn der Server seine Warteschlange leert, kann er den Schreibzähler in den Ruhezustand versetzen. Ein Client kann über eine RDMA-Transaktion über die Hardware Daten oder eine Nachricht in die RBQ-Segmentwarteschlange stellen, den RDMA-Zähler inkrementieren und den Server aufwecken.
  • Nach dem Aufwachen kann der Server den Semaphorwert überprüfen, und wenn Daten in die Warteschlange eingegangen sind, kann der Server alle Daten in der Warteschlange (über RDMA) verarbeiten und den RDMA-Zähler auf „0“ zurücksetzen. Wenn der Semaphor immer noch gesperrt ist (was durch den Semaphorwert widergespiegelt wird), bedeutet dies, dass der RDMA-Zähler auf eine andere Transaktion im Speicherbereich reagiert hat, und der Server kann in den Ruhezustand zurückkehren.
  • So können die Knoten in einem verteilten System (wie FAMfs) ein clusterweites RBQ für die gesamte Kommunikation zwischen den Knoten verwenden. Dieses clusterweite RBQ kann als partitionierte Segmente implementiert werden, die mehreren Knoten (z. B. Serverknoten, Zuweisungsknoten oder E/A-Knoten in FAMfs) im verteilten System zugewiesen werden.
  • Beispielhaftes Verfahren zur Erleichterung der gemeinsamen Nutzung atomarer Daten
  • zeigt ein Flussdiagramm 500, das ein Verfahren veranschaulicht, das einen LFA-basierten gemeinsamen Speicherzugriff in einem verteilten System gemäß einem Aspekt der vorliegenden Anwendung ermöglicht. Während des Betriebs weist das System in einem verteilten System, das eine Vielzahl von Knoten umfasst, eine Vielzahl von Speicherabschnitten zu, die gemeinsam genutzte entfernte Speicherinhalte umfassen (Vorgang 502). Das System registriert die zugewiesenen Teile bei einem Betriebssystem, um über direkten Fernspeicherzugriff darauf zugreifen zu können (Vorgang 504). Das System greift über einen ersten Knoten auf die zugewiesenen Teile zu, um eine lokale Kopie des gemeinsamen entfernten Speicherinhalts zu erhalten (Vorgang 506). Das System führt eine atomare Operation an einem oder mehreren Bits des gemeinsam genutzten entfernten Speicherinhalts über libfabric atomic (LFA)-Anwendungsprogrammierschnittstellenaufrufe (API) durch (Vorgang 508), indem es eine oder mehrere der folgenden Operationen ausführt. Das System aktualisiert das eine oder die mehreren Bits des gemeinsamen entfernten Speicherinhalts basierend auf einem neuen Wert und einem Offset (Operation 510). Das System ruft aus dem gemeinsam genutzten entfernten Speicherinhalt basierend auf dem Offset einen aktuellen Wert des einen oder der mehreren Bits vor der Aktualisierung ab (Operation 512). Das System führt eine Aktion an dem gemeinsam genutzten entfernten Speicherinhalt auf der Grundlage eines Vergleichs des aktuellen Werts mit einem erwarteten Wert in der lokalen Kopie durch (Vorgang 514).
  • zeigt ein Flussdiagramm 520, das ein Verfahren veranschaulicht, das einen LFA-basierten gemeinsamen Speicherzugriff in einem verteilten System in Übereinstimmung mit einem Aspekt der vorliegenden Anwendung ermöglicht. Während des Betriebs weist das System in einem verteilten System, das eine Vielzahl von Knoten umfasst, eine Vielzahl von Speicherabschnitten zu, die gemeinsam genutzte entfernte Speicherinhalte umfassen (Vorgang 522). Das System registriert die zugewiesenen Teile bei einem Betriebssystem, um über direkten Fernspeicherzugriff darauf zugreifen zu können (Vorgang 524). Das System greift über einen ersten Knoten auf die zugewiesenen Teile zu, um eine lokale Kopie des gemeinsamen entfernten Speicherinhalts zu erhalten (Vorgang 526). Das System führt eine atomare Operation an der lokalen Kopie durch, indem es in der lokalen Kopie auf der Grundlage eines neuen Wertes und eines Offsets ein gemeinsames Objekt aktualisiert, das einem oder mehreren Bits des gemeinsamen entfernten Speicherinhalts entspricht (Vorgang 528). Das System ruft aus dem gemeinsamen entfernten Speicherinhalt auf der Grundlage des Offsets einen aktuellen Wert des einen oder der mehreren Bits ab (Vorgang 530). Das System vergleicht den abgerufenen aktuellen Wert mit einem erwarteten Wert in der lokalen Kopie (Vorgang 532).
  • Wenn der aktuelle Wert nicht mit dem erwarteten Wert übereinstimmt (Entscheidung 534), erhält das System eine Fehlermeldung und behebt die Fehler (z. B. um eine Kollision zu beheben) (Vorgang 536). Wenn der aktuelle Wert mit dem erwarteten Wert übereinstimmt (Entscheidung 534), führt das System die atomare Operation an dem einen oder den mehreren Bits des gemeinsam genutzten entfernten Speichers über libfabric atomic (LFA)-Aufrufe der Anwendungsprogrammierschnittstelle (API) durch (Operation 538). Die Operation wird entweder bei Label A von oder Label B von fortgesetzt.
  • Beispielhaftes Verfahren für den Zugriff auf Dateien und die Verwendung einer gemeinsamen Ringpuffer-Warteschlange
  • zeigt ein Flussdiagramm 600, das ein Verfahren veranschaulicht, das den Zugriff auf Dateien in einem Dateisystem unter Verwendung eines LFA-basierten gemeinsamen Speicherzugriffs in einem verteilten System in Übereinstimmung mit einem Aspekt der vorliegenden Anwendung erleichtert. Der entfernte gemeinsam genutzte Speicherinhalt umfasst ein Inhaltsverzeichnis für Dateien und ein oder mehrere Zählerarrays, die zugewiesenen Speicherabschnitte umfassen Partitionen des Inhaltsverzeichnisses und des einen oder der mehreren Zählerarrays, und den Dateien entsprechende Einträge im Inhaltsverzeichnis umfassen: einen Referenzzählwert, der eine Anzahl von Prozessen angibt, die derzeit eine entsprechende Datei geöffnet haben; und einen Offset zu einem Element in einem der Zählerarrays (Vorgang 602). Das System empfängt eine Anforderung zum Öffnen einer Datei mit einer zugehörigen Dateikennung im verteilten System (Vorgang 604). Ein Dateisystem (z. B. FAMfs), das mit dem verteilten System verbunden ist, kann auf den gemeinsamen entfernten Speicherinhalt zugreifen. Das System bestimmt eine Partition des Inhaltsverzeichnisses, die den Dateibezeichner enthält (Vorgang 606). Wie oben beschrieben, kann der Client zunächst eine Suche nach dem Dateibezeichner in seiner lokalen Kopie des TOC durchführen, ohne einen Spinlock zu erwerben. Wenn die Dateikennung in der lokalen TOC nicht vorhanden ist (nicht gezeigt), erhält das System einen Spinlock für die Partition des Inhaltsverzeichnisses (Vorgang 608). Das System durchsucht die Partition des Inhaltsverzeichnisses, um einen Eintrag zu erhalten, der dem Dateibezeichner entspricht, wobei der Eintrag Folgendes umfasst: einen ersten Referenzzählwert; und einen ersten Offset zu einem Element in einem ersten Zählerarray, wobei das Element einen Zählwert einer dem Dateibezeichner zugeordneten Aktion umfasst (Operation 610). Als Reaktion auf das Auffinden des Eintrags erhöht das System den ersten Referenzzählwert (Operation 612). Das System gibt den Spinlock für die Partition des Inhaltsverzeichnisses frei (Operation 614) und greift auf das erste Zählerfeld beim ersten Offset zu, um den Zählerstand der Aktion zu erhöhen (Operation 616). Die Operation kehrt zurück.
  • zeigt ein Flussdiagramm 620, das ein Verfahren veranschaulicht, das die Übermittlung von Nachrichten über eine gemeinsam genutzte Ringpuffer-Warteschlange unter Verwendung eines LFA-basierten gemeinsamen Speicherzugriffs in einem verteilten System gemäß einem Aspekt der vorliegenden Anwendung erleichtert. Der entfernte gemeinsam genutzte Speicherinhalt umfasst eine globale Ringpuffer-Warteschlange, die zugewiesenen Speicherabschnitte umfassen Segmente der globalen Ringpuffer-Warteschlange, und ein jeweiliges Segment umfasst: eine Warteschlange, in der Daten, einschließlich Nachrichten, gespeichert werden; ein Eingangssemaphor und ein Ausgangssemaphor, um den Zugriff auf die Warteschlange zu synchronisieren; und einen Eingangszeiger und einen Ausgangszeiger, um Positionen zu verfolgen, die sich auf Einfüge- und Entnahmeoperationen beziehen, die an der Warteschlange durchgeführt werden (Vorgang 622). Das System greift durch einen ersten Client-Knoten auf das jeweilige Segment der globalen Ringpuffer-Warteschlange zu, das den entfernten gemeinsamen Speicherinhalt enthält (Vorgang 624). Das System erfasst das Eingangssemaphor durch Dekrementieren des Eingangssemaphors (Operation 626). Als Reaktion auf die erfolgreiche Erfassung des Eingangssemaphors inkrementiert das System den Eingangszeiger (Vorgang 628). Das System sendet über RDMA Daten an eine Speicherstelle, auf die der Eingabezeiger zeigt (Vorgang 630). Das System gibt den Ausgangssemaphor frei, indem es den Ausgangssemaphor inkrementiert (Vorgang 632), und der Vorgang wird mit dem Label C von fortgesetzt.
  • zeigt ein Flussdiagramm 640, das ein Verfahren veranschaulicht, das die Zustellung von Nachrichten über eine gemeinsam genutzte Ringpuffer-Warteschlange unter Verwendung eines LFA-basierten gemeinsamen Speicherzugriffs in einem verteilten System gemäß einem Aspekt der vorliegenden Anwendung erleichtert. Das System greift durch einen ersten Serverknoten, der das jeweilige Segment zugewiesen hat, auf das jeweilige Segment zu (Vorgang 642). Das System stellt fest, dass das Ausgangssemaphor einen Wert größer als Null hat (Operation 644). Das System erwirbt das Ausgangssemaphor durch Dekrementieren des Ausgangssemaphors (Vorgang 646). Das System ruft über RDMA die Daten ab, die an der Speicherstelle gespeichert sind, auf die der Ausgabezeiger zeigt (Vorgang 648). Das System inkrementiert den Ausgangszeiger (Vorgang 650) und gibt den Eingangssemaphor frei, indem es den Eingangssemaphor inkrementiert (Vorgang 652). Die Operation kehrt zurück.
  • Beispielhaftes Computersystem und -Gerät
  • zeigt ein beispielhaftes Computersystem 700, das die dynamische Zuweisung von Speicherplatz in einem verteilten Dateisystem in Übereinstimmung mit einem Aspekt der vorliegenden Anwendung erleichtert. Das Computersystem 700 umfasst einen Prozessor 702, einen flüchtigen Speicher 706 und ein Speichergerät 708. In einigen Aspekten kann das Computersystem 700 einen Controller 704 enthalten (durch die gestrichelten Linien gekennzeichnet). Der flüchtige Speicher 706 kann z. B. einen Direktzugriffsspeicher (RAM) umfassen, der als verwalteter Speicher dient und zum Speichern eines oder mehrerer Speicherpools verwendet werden kann. Die Speichervorrichtung 708 kann einen dauerhaften Speicher enthalten, der über den Prozessor 702 (oder den Controller 704) verwaltet werden kann oder auf den er zugreifen kann. Darüber hinaus kann das Computersystem 700 mit peripheren Eingabe-/Ausgabe-Benutzergeräten 710 gekoppelt sein, z. B. mit einem Anzeigegerät 711, einer Tastatur 712 und einem Zeigegerät 714. Das Speichergerät 708 kann ein Betriebssystem 716, ein inhaltsverarbeitendes System 718 und Daten 736 speichern.
  • Das Inhaltsverarbeitungssystem 718 kann Anweisungen enthalten, die, wenn sie vom Computersystem 700 ausgeführt werden, das Computersystem 700 oder den Prozessor 702 veranlassen können, die in dieser Offenbarung beschriebenen Verfahren und/oder Prozesse durchzuführen. Insbesondere kann das inhaltsverarbeitende System 718 Anweisungen zum Empfangen und Senden von Datenpaketen enthalten, die mit einem LFA-API-Aufruf (Kommunikationsmodul 720) verbunden sind.
  • Das inhaltsverarbeitende System 718 kann ferner Anweisungen enthalten, um in einem verteilten System mit einer Vielzahl von Knoten eine Vielzahl von Speicherabschnitten zuzuweisen, die einen gemeinsam genutzten entfernten Speicherinhalt umfassen (Speicherabschnittszuweisungsmodul 722). Das inhaltsverarbeitende System 718 kann Anweisungen zum Registrieren der zugewiesenen Teile bei einem Betriebssystem enthalten, damit auf sie über direkten Fernspeicherzugriff (RDMA) zugegriffen werden kann (Speicherteil-Zuweisungsmodul 722). Das inhaltsverarbeitende System 718 kann Anweisungen für den Zugriff eines ersten Knotens auf die zugewiesenen Teile enthalten, um eine lokale Kopie des gemeinsam genutzten entfernten Speicherinhalts zu erhalten (Modul 724 zum Anhängen von Teilen). Das inhaltsverarbeitende System 718 kann auch Anweisungen zur Durchführung einer atomaren Operation an einem oder mehreren Bits des gemeinsam genutzten entfernten Speicherinhalts über libfabric atomic (LFA) Application Programming Interface (API)-Aufrufe (LFA-API-Aufrufmodul 726) enthalten.
  • Das inhaltsverarbeitende System 718 kann zusätzlich Anweisungen zum Aktualisieren des einen oder der mehreren Bits des gemeinsam genutzten entfernten Speicherinhalts auf der Grundlage eines neuen Werts und eines Offsets enthalten (LFA-API-Aufrufmodul 726 und Bitmap-Verwaltungsmodul 730). Das inhaltsverarbeitende System 718 kann Anweisungen zum Abrufen eines aktuellen Werts des einen oder der mehreren Bits aus dem gemeinsam genutzten entfernten Speicherinhalt auf der Grundlage des Offsets vor der Aktualisierung enthalten (LFA-API-Aufrufmodul 726 und Bitmap-Verwaltungsmodul 730). Das inhaltsverarbeitende System 718 kann Anweisungen zur Durchführung einer Aktion mit dem gemeinsam genutzten entfernten Speicherinhalt auf der Grundlage eines Vergleichs des abgerufenen aktuellen Werts mit einem erwarteten Wert in der lokalen Kopie enthalten (LFA-API-Aufrufmodul 726 und Bitmap-Verwaltungsmodul 730).
  • Das inhaltsverarbeitende System 718 kann ferner Anweisungen für den Zugriff auf ein Inhaltsverzeichnis für Dateien und ein oder mehrere Zählerarrays enthalten, wie oben in Bezug auf beschrieben (TOC-Verwaltungsmodul 732). Das Inhaltsverarbeitungssystem 718 kann Anweisungen für den Zugriff auf eine Warteschlange (z. B. eine Nachrichtenwarteschlange) in einem Segment einer globalen Ringpuffer-Warteschlange enthalten, wie oben in Bezug auf die und beschrieben (Warteschlangen-Verwaltungsmodul 734).
  • Zu den Daten 736 können alle Daten gehören, die von den in dieser Offenlegung beschriebenen Methoden und/oder Prozessen als Eingabe benötigt oder als Ausgabe erzeugt werden. Insbesondere können die Daten 736 mindestens Folgendes speichern eine virtuelle Kopie einer globalen Datenstruktur; eine lokale Kopie einer globalen Datenstruktur; einen Indikator eines Segments, einer Partition, eines Blob oder eines Teils des zugewiesenen Speichers; einen Indikator oder Identifikator eines Knotens, eines Server-Knotens oder eines Client-Knotens; einen LFA-API-Aufruf; eine atomare Operation; eine arithmetische Operation; eine logische Operation; einen Wert; einen aktuellen Wert, einen erwarteten Wert oder einen neuen Wert; ein oder mehrere Bits; eine Bitmap-Datenstruktur; einen Eintrag; ein Inhaltsverzeichnis; einen Dateibezeichner; einen Referenzzähler; einen Offset; einen Spinlock; eine globale Ringpuffer-Warteschlange; eine Warteschlange; eine Nachrichtenwarteschlange; Daten; atomare Daten; kodierte oder dekodierte Daten; laminierte Daten; einen Status; ein Wort; ein gemeinsam genutztes Objekt; Nachrichtendaten; einen Wert für einen Eingabezeiger, einen Ausgabezeiger, eine Eingabe-Semaphor oder eine Ausgabe-Semaphor; einen Indikator für ein Dateisystem oder ein anderes verteiltes System; einen Indikator für ein FAM-Modul oder ein anderes NVMe-Gerät; eine Extent-Bitmap; und eine Extent-Map.
  • zeigt eine beispielhafte Vorrichtung 800, die die dynamische Zuweisung von Speicherplatz in einem verteilten Dateisystem gemäß einem Aspekt der vorliegenden Anwendung erleichtert. Die Vorrichtung 800 kann eine Vielzahl von Einheiten oder Geräten umfassen, die über einen verdrahteten, drahtlosen, Quantenlicht- oder elektrischen Kommunikationskanal miteinander kommunizieren können. Die Vorrichtung 800 kann unter Verwendung eines oder mehrerer integrierter Schaltkreise realisiert werden und kann weniger oder mehr Einheiten oder Vorrichtungen als die in gezeigten umfassen. Darüber hinaus kann die Vorrichtung 800 in ein Computersystem integriert oder als separates Gerät oder Geräte realisiert werden, die mit anderen Computersystemen und/oder Geräten kommunizieren können.
  • Vorrichtung 800 kann auch ein nichtflüchtiges Speichersystem oder eine Speicherverwaltungseinheit enthalten. Vorrichtung 800 kann Module oder Einheiten 802-816 umfassen, die so konfiguriert sind, dass sie ähnliche Funktionen oder Operationen wie die Module 720-734 des Computersystems 700 von ausführen, einschließlich: einer Kommunikationseinheit 802; einer Speicherteil-Zuweisungseinheit 804; einer Teil-Anfügeeinheit 806; einer LFA-API-Aufrufeinheit 808; einer lokalen Kopierverwaltungseinheit 810; einer Bitmap-Verwaltungseinheit 812; einer TOC-Verwaltungseinheit 814; und einer Warteschlangen-Verwaltungseinheit 816.
  • Im Allgemeinen stellen die offenbarten Aspekte ein System bereit, das eine LFA-basierte sperrfreie clusterweite gemeinsame Speicherzugriffs-API in einem verteilten System ermöglicht. In einem Aspekt weist das System in einem verteilten System, das eine Vielzahl von Knoten umfasst, eine Vielzahl von Speicherabschnitten zu, die einen gemeinsam genutzten entfernten Speicherinhalt umfassen. Das System registriert die zugewiesenen Teile bei einem Betriebssystem für den Zugriff über direkten Fernspeicherzugriff (RDMA). Das System greift über einen ersten Knoten auf die zugewiesenen Teile zu, um eine lokale Kopie des gemeinsamen entfernten Speicherinhalts zu erhalten. Das System führt eine atomare Operation an einem oder mehreren Bits des gemeinsam genutzten entfernten Speicherinhalts über libfabric atomic (LFA)-Anwendungsprogrammierschnittstellen (API)-Aufrufe durch, die eines oder mehrere der folgenden Elemente umfasst: Aktualisieren des einen oder der mehreren Bits des gemeinsam genutzten entfernten Speicherinhalts auf der Grundlage eines neuen Werts und eines Offsets; Abrufen eines aktuellen Werts des einen oder der mehreren Bits vor dem Aktualisieren aus dem gemeinsam genutzten entfernten Speicherinhalt auf der Grundlage des Offsets; und Durchführen einer Aktion an dem gemeinsam genutzten entfernten Speicherinhalt auf der Grundlage eines Vergleichs des abgerufenen aktuellen Werts mit einem erwarteten Wert in der lokalen Kopie.
  • In einer Variante dieses Aspekts führt das System die Aktion mit dem gemeinsamen entfernten Speicherinhalt durch die folgenden Operationen aus. Als Reaktion auf die Feststellung, dass der aktuelle Wert nicht mit dem erwarteten Wert übereinstimmt, empfängt das System eine Fehlermeldung. Als Reaktion auf die Feststellung, dass der aktuelle Wert mit dem erwarteten Wert übereinstimmt, führt das System die atomare Operation an dem einen oder den mehreren Bits des gemeinsam genutzten entfernten Speicherinhalts durch, wobei der Offset einen globalen Offset in dem gemeinsam genutzten entfernten Speicherinhalt umfasst, der mit dem einen oder den mehreren Bits verbunden ist.
  • In einer weiteren Variante dieses Aspekts führt das System die atomare Operation an der lokalen Kopie durch, indem es in der lokalen Kopie auf der Grundlage des neuen Wertes und des Offsets ein gemeinsames Objekt aktualisiert, das dem einen oder den mehreren Bits des gemeinsamen entfernten Speicherinhalts entspricht.
  • In einer weiteren Variante umfasst die atomare Operation eines oder mehrere der folgenden Elemente: Durchführen einer arithmetischen Operation an dem einen oder den mehreren Bits, einschließlich einer oder mehrerer Additions- und Subtraktionsoperationen; und Durchführen einer logischen bitweisen Operation an dem einen oder den mehreren Bits, einschließlich einer oder mehrerer AND-Operationen, OR-Operationen und exklusiver OR-Operationen (XOR).
  • In einer weiteren Variante umfasst die Vielzahl von Knoten Server-Knoten und Client-Knoten, wobei die Server-Knoten die Vielzahl von Speicherabschnitten zuweisen und der erste Knoten ein Client-Knoten oder ein Server-Knoten ist. Die Client-Knoten führen die atomare Operation durch, indem sie in einem ersten zugewiesenen Teil, der auf dem neuen Wert und dem Offset basiert, ein gemeinsames Objekt anhängen, das dem einen oder mehreren Bits entspricht.
  • In einer anderen Variante dieses Aspekts wird auf den gemeinsam genutzten entfernten Speicherinhalt über ein Dateisystem zugegriffen, das mit dem verteilten System verbunden ist, und das Dateisystem ist ein Fabric Attached Memory Filesystem (FAMfs). Die Serverknoten sind E/A-Knoten im FAMfs. Die Zuweisung der mehreren Speicherabschnitte erfolgt durch Zuweisungsmodule, die mit jedem E/A-Knoten im FAMfs verbunden sind, und der gemeinsam genutzte Fernspeicherinhalt umfasst eine Bitmap-Datenstruktur, die einen Status, wie verwendet oder frei, von physischen Ausmaßen im Speicher des FAMfs verfolgt.
  • In einer weiteren Variante umfasst der gemeinsam genutzte Fernspeicherinhalt ein Inhaltsverzeichnis für Dateien und ein oder mehrere Zähler-Arrays, und die zugewiesenen Speicherbereiche umfassen Partitionen des Inhaltsverzeichnisses und des einen oder der mehreren Zähler-Arrays. Die Einträge, die den Dateien in der Inhaltstabelle entsprechen, umfassen: einen Referenzzählwert, der die Anzahl der Prozesse angibt, die derzeit eine entsprechende Datei geöffnet haben, und einen Offset zu einem Element in einem der Zähler-Arrays.
  • In einer weiteren Variante dieses Aspekts empfängt das System eine Anforderung zum Öffnen einer Datei mit einer zugehörigen Dateikennung im verteilten System. Das System bestimmt eine Partition des Inhaltsverzeichnisses, die den Dateibezeichner enthält. Das System erhält einen Spinlock für die Partition des Inhaltsverzeichnisses. Das System durchsucht die Partition des Inhaltsverzeichnisses, um einen Eintrag zu erhalten, der dem Dateibezeichner entspricht. Der Eintrag umfasst: einen ersten Referenzzählwert; und einen ersten Offset zu einem Element in einem ersten Zählerarray, wobei das Element einen Zählwert einer mit dem Dateibezeichner verbundenen Aktion umfasst. Als Reaktion auf das Auffinden des Eintrags inkrementiert das System den ersten Referenzzähler. Das System gibt den Spinlock für die Partition des Inhaltsverzeichnisses frei und greift auf das erste Zähler-Array am ersten Offset zu, um den Zählerstand der Aktion zu erhöhen.
  • In einer anderen Variante dieses Aspekts umfasst der entfernte gemeinsame Speicherinhalt eine globale Ringpuffer-Warteschlange, und die zugewiesenen Speicherabschnitte umfassen Segmente der globalen Ringpuffer-Warteschlange. Ein jeweiliges Segment umfasst: eine Warteschlange, in der Daten, einschließlich Nachrichten, gespeichert werden; einen Eingabe- und einen Ausgabesemaphor, um den Zugriff auf die Warteschlange zu synchronisieren; und einen Eingabezeiger und einen Ausgabezeiger, um Positionen zu verfolgen, die sich auf Einfüge- und Entnahmeoperationen beziehen, die in der Warteschlange durchgeführt werden.
  • In einer weiteren Variante greift das System über den ersten Client-Knoten auf das jeweilige Segment zu, indem es die folgenden Operationen durchführt. Das System erfasst den Eingangssemaphor, indem es den Eingangssemaphor dekrementiert. Als Reaktion auf die erfolgreiche Erfassung des Eingabesemaphors inkrementiert das System den Eingabezeiger. Das System sendet über RDMA Daten an eine Speicherstelle, auf die der Eingabezeiger zeigt, und das System gibt das Ausgangssemaphor frei, indem es das Ausgangssemaphor inkrementiert.
  • In einer weiteren Variante greift das System über einen ersten Serverknoten, der das jeweilige Segment zugewiesen hat, auf das jeweilige Segment zu, indem es die folgenden Operationen durchführt. Das System stellt fest, dass der Ausgangssemaphor einen Wert größer als Null hat. Das System erwirbt das Ausgangssemaphor, indem es das Ausgangssemaphor dekrementiert, und ruft über RDMA die Daten ab, die an der Speicherstelle gespeichert sind, auf die der Ausgangszeiger zeigt. Das System inkrementiert den Ausgangszeiger und gibt den Eingangssemaphor frei, indem es den Eingangssemaphor inkrementiert
  • Die in dieser ausführlichen Beschreibung beschriebenen Datenstrukturen und der Code werden in der Regel auf einem computerlesbaren Speichermedium gespeichert, bei dem es sich um ein beliebiges Gerät oder Medium handeln kann, das Code und/oder Daten zur Verwendung durch ein Computersystem speichern kann. Das computerlesbare Speichermedium umfasst unter anderem flüchtige Speicher, nichtflüchtige Speicher, magnetische und optische Speichervorrichtungen wie Plattenlaufwerke, Magnetbänder, CDs (Compact Discs), DVDs (Digital Versatile Discs oder Digital Video Discs) oder andere Medien, die in der Lage sind, heute bekannte oder später entwickelte computerlesbare Medien zu speichern.
  • Die im Abschnitt „Detaillierte Beschreibung“ beschriebenen Methoden und Prozesse können als Code und/oder Daten verkörpert werden, die wie oben beschrieben in einem computerlesbaren Speichermedium gespeichert werden können. Wenn ein Computersystem den auf dem computerlesbaren Speichermedium gespeicherten Code und/oder die Daten liest und ausführt, führt das Computersystem die Methoden und Prozesse aus, die als Datenstrukturen und Code verkörpert und in dem computerlesbaren Speichermedium gespeichert sind.
  • Darüber hinaus können die oben beschriebenen Methoden und Prozesse in Hardwaregeräte oder -vorrichtungen integriert werden. Zu den Hardware-Bauteilen oder -Vorrichtungen können beispielsweise anwendungsspezifische integrierte Schaltungen (ASIC), feldprogrammierbare Gate-Arrays (FPGA), dedizierte oder gemeinsam genutzte Prozessoren, die ein bestimmtes Softwareprogramm oder ein Stück Code zu einem bestimmten Zeitpunkt ausführen, und andere bekannte oder später entwickelte programmierbare Logikbauteile gehören, ohne darauf beschränkt zu sein. Wenn die Hardware-Geräte oder -Vorrichtungen aktiviert werden, führen die Hardware-Module die in ihnen enthaltenen Methoden und Prozesse aus.
  • Die vorstehenden Beschreibungen von Aspekten dienen lediglich der Veranschaulichung und Beschreibung. Sie erheben keinen Anspruch auf Vollständigkeit und beschränken die hier beschriebenen Aspekte nicht auf die dargestellten Formen. Dementsprechend werden viele Modifikationen und Variationen für Fachleute auf dem Gebiet der Technik offensichtlich sein. Darüber hinaus soll die obige Offenlegung die hierin beschriebenen Aspekte nicht einschränken. Der Umfang der hierin beschriebenen Aspekte wird durch die beigefügten Ansprüche definiert.

Claims (20)

  1. Ein computer-implementiertes Verfahren, das Folgendes umfasst: Zuteilung einer Vielzahl von Speicherabschnitten in einem verteilten System, das eine Vielzahl von Knoten umfasst, die einen gemeinsamen entfernten Speicherinhalt umfassen; Registrierung der zugewiesenen Teile bei einem Betriebssystem für den Zugriff über direkten Fernspeicherzugriff (RDMA); Zugreifen auf die zugewiesenen Teile durch einen ersten Knoten, um eine lokale Kopie des gemeinsamen entfernten Speicherinhalts zu erhalten; und Durchführung einer atomaren Operation an einem oder mehreren Bits des gemeinsam genutzten entfernten Speicherinhalts über libfabric atomic (LFA) Application Programming Interface (API)-Aufrufe, die eines oder mehrere der folgenden Elemente umfassen: Aktualisieren des einen oder der mehreren Bits des gemeinsamen Fernspeicherinhalts auf der Grundlage eines neuen Werts und eines Offsets; Abrufen eines aktuellen Wertes des einen oder der mehreren Bits aus dem gemeinsamen entfernten Speicherinhalt auf der Grundlage des Offsets vor der Aktualisierung; und Durchführen einer Aktion mit dem gemeinsamen entfernten Speicherinhalt auf der Grundlage eines Vergleichs des abgerufenen aktuellen Werts mit einem erwarteten Wert in der lokalen Kopie.
  2. Das Verfahren nach Anspruch 1, wobei das Durchführen der Aktion auf dem gemeinsamen entfernten Speicherinhalt umfasst: als Reaktion auf die Feststellung, dass der aktuelle Wert nicht mit dem erwarteten Wert übereinstimmt, Empfang einer Fehlermeldung; und als Reaktion auf die Feststellung, dass der aktuelle Wert mit dem erwarteten Wert übereinstimmt, Durchführen der atomaren Operation an dem einen oder den mehreren Bits des gemeinsamen Fernspeicherinhalts, wobei der Offset einen globalen Offset in dem gemeinsamen entfernten Speicherinhalt umfasst, der mit dem einen oder den mehreren Bits verbunden ist.
  3. Das Verfahren nach Anspruch 1 umfasst ferner: Durchführen der atomaren Operation an der lokalen Kopie durch Aktualisieren eines gemeinsamen Objekts, das dem einen oder den mehreren Bits des gemeinsamen entfernten Speicherinhalts entspricht, in der lokalen Kopie auf der Grundlage des neuen Werts und des Offsets.
  4. Das Verfahren nach Anspruch 1, wobei die atomare Operation eines oder mehrere der folgenden Elemente umfasst: Durchführen einer arithmetischen Operation an dem einen oder den mehreren Bits, einschließlich einer oder mehrerer Additions- und Subtraktionsoperationen; und Durchführen einer logischen bitweisen Operation an dem einen oder den mehreren Bits, einschließlich einer oder mehrerer AND-Operationen, einer OR-Operation und einer exklusiven OR-Operation (XOR).
  5. Das Verfahren nach Anspruch 1, wobei die Mehrzahl der Knoten Serverknoten und Clientknoten umfasst, wobei die Serverknoten die Vielzahl von Speicherabschnitten zuweisen, wobei der erste Knoten ein Client-Knoten oder ein Server-Knoten ist, und wobei die Client-Knoten die atomare Operation durchführen, indem sie in einem ersten zugewiesenen Teil, der auf dem neuen Wert und dem Offset basiert, an ein gemeinsames Objekt anhängen, das dem einen oder den mehreren Bits entspricht.
  6. Das Verfahren nach Anspruch 5, wobei auf den gemeinsam genutzten entfernten Speicherinhalt durch ein mit dem verteilten System verbundenes Dateisystem zugegriffen wird, wobei das Dateisystem ein Fabric Attached Memory Filesystem (FAMfs) ist, wobei die Serverknoten E/A-Knoten in den FAMfs sind, wobei die Zuweisung der mehreren Speicherabschnitte durch Zuweisungsmodule erfolgt, die mit jedem E/A-Knoten in den FAMfs verbunden sind, und wobei der Inhalt des gemeinsam genutzten Fernspeichers eine Bitmap-Datenstruktur umfasst, die einen Status, wie verwendet oder frei, von physischen Ausmaßen im Speicher der FAMfs verfolgt.
  7. Das Verfahren nach Anspruch 6, wobei der Inhalt des gemeinsam genutzten Fernspeichers ein Inhaltsverzeichnis für Dateien und ein oder mehrere Zählerarrays umfasst, wobei die zugewiesenen Speicherabschnitte Partitionen des Inhaltsverzeichnisses und des einen oder der mehreren Zählerarrays umfassen, und wobei die Einträge, die den Dateien im Inhaltsverzeichnis entsprechen, umfassen: eine Referenzzahl, die die Anzahl der Prozesse angibt, die derzeit eine entsprechende Datei geöffnet haben; und ein Offset zu einem Element in einem der Zähler-Arrays.
  8. Das Verfahren nach Anspruch 7 umfasst ferner: Empfang einer Anforderung zum Öffnen einer Datei mit einem zugehörigen Dateibezeichner in dem verteilten System; Bestimmung einer Partition des Inhaltsverzeichnisses, die den Dateibezeichner enthält; Beschaffung eines Spinlocks für die Partition des Inhaltsverzeichnisses; Durchsuchen der Partition des Inhaltsverzeichnisses, um einen Eintrag zu erhalten, der der Dateikennung entspricht, wobei der Eintrag umfasst: eine erste Referenzzahl; und einen ersten Versatz zu einem Element in einem ersten Zähler-Array, wobei das Element einen Zählwert einer mit dem Dateibezeichner verbundenen Aktion umfasst; Als Reaktion auf das Auffinden des Eintrags wird der erste Referenzwert erhöht; Freigabe des Spinlocks für die Partition des Inhaltsverzeichnisses; und Zugriff auf das erste Zählerfeld beim ersten Offset, um den Zählerstand der Aktion zu erhöhen.
  9. Das Verfahren nach Anspruch 5, wobei der entfernte gemeinsame Speicherinhalt eine globale Ringpuffer-Warteschlange umfasst, wobei die zugewiesenen Speicherabschnitte Segmente der globalen Ringpuffer-Warteschlange umfassen, und wobei ein jeweiliges Segment umfasst: eine Warteschlange, in der Daten, einschließlich Nachrichten, gespeichert werden können; einen Eingangssemaphor und einen Ausgangssemaphor, um den Zugriff auf die Warteschlange zu synchronisieren; und einen Eingabezeiger und einen Ausgabezeiger, um Positionen zu verfolgen, die sich auf Einfüge- und Entnahmevorgänge in der Warteschlange beziehen.
  10. Das Verfahren nach Anspruch 9, ferner umfassend den Zugriff durch den ersten Client-Knoten auf das jeweilige Segment durch: Erfassen des Eingangssemaphors durch Dekrementieren des Eingangssemaphors; als Reaktion auf die erfolgreiche Erfassung des Eingangssemaphors, Inkrementieren des Eingangszeigers; Senden von Daten über RDMA an eine Speicherstelle, auf die der Eingabezeiger zeigt; und Freigabe des Ausgangssemaphors durch Inkrementierung des Ausgangssemaphors.
  11. Das Verfahren nach Anspruch 9, das ferner umfasst, dass ein erster Serverknoten, der das jeweilige Segment zugewiesen hat, auf das jeweilige Segment zugreift, indem er: die Feststellung, dass das Ausgangssemaphor einen Wert größer als Null hat; das Erfassen des Ausgangssemaphors durch Dekrementieren des Ausgangssemaphors; Abruf der Daten, die an dem Speicherplatz gespeichert sind, auf den der Ausgabezeiger zeigt, über RDMA; Inkrementieren des Ausgabezeigers; und Freigabe des Eingangssemaphors durch Inkrementierung des Eingangssemaphors.
  12. Ein Computersystem, das Folgendes umfasst: einen Prozessor; und einen Speicher, der mit dem Prozessor verbunden ist und Befehle speichert, die, wenn sie von dem Prozessor ausgeführt werden, den Prozessor veranlassen, ein Verfahren durchzuführen, wobei das Verfahren umfasst: Zuteilung einer Vielzahl von Speicherabschnitten in einem verteilten System, das eine Vielzahl von Knoten umfasst, die einen gemeinsamen entfernten Speicherinhalt umfassen; Registrierung der zugewiesenen Teile bei einem Betriebssystem für den Zugriff über direkten Fernspeicherzugriff (RDMA); Zugreifen auf die zugewiesenen Teile durch einen ersten Knoten, um eine lokale Kopie des gemeinsamen entfernten Speicherinhalts zu erhalten; und Durchführung einer atomaren Operation an einem oder mehreren Bits des gemeinsam genutzten entfernten Speicherinhalts über libfabric atomic (LFA) Application Programming Interface (API)-Aufrufe, die eines oder mehrere der folgenden Elemente umfassen: Aktualisieren des einen oder der mehreren Bits des gemeinsamen Fernspeicherinhalts auf der Grundlage eines neuen Werts und eines Offsets; Abrufen eines aktuellen Wertes des einen oder der mehreren Bits aus dem gemeinsamen entfernten Speicherinhalt auf der Grundlage des Offsets vor der Aktualisierung; und Durchführen einer Aktion an dem gemeinsam genutzten entfernten Speicherinhalt auf der Grundlage eines Vergleichs des abgerufenen aktuellen Werts mit einem erwarteten Wert in der lokalen Kopie.
  13. Das Computersystem nach Anspruch 12, wobei das Durchführen der Aktion auf dem gemeinsamen entfernten Speicherinhalt umfasst: als Reaktion auf die Feststellung, dass der aktuelle Wert nicht mit dem erwarteten Wert übereinstimmt, Empfang einer Fehlermeldung; und als Reaktion auf die Feststellung, dass der aktuelle Wert mit dem erwarteten Wert übereinstimmt, Durchführen der atomaren Operation an dem einen oder den mehreren Bits des gemeinsamen Fernspeicherinhalts, wobei der Offset einen globalen Offset in dem gemeinsamen entfernten Speicherinhalt umfasst, der mit dem einen oder den mehreren Bits verbunden ist.
  14. Das Computersystem nach Anspruch 12, wobei das Verfahren weiterhin umfasst: Durchführen der atomaren Operation an der lokalen Kopie durch Aktualisieren eines gemeinsamen Objekts, das dem einen oder den mehreren Bits des gemeinsamen entfernten Speicherinhalts entspricht, in der lokalen Kopie auf der Grundlage des neuen Werts und des Offsets.
  15. Das Computersystem nach Anspruch 12, wobei die Vielzahl von Knoten Serverknoten und Clientknoten umfasst, wobei die Serverknoten die Vielzahl von Speicherabschnitten zuweisen, wobei der erste Knoten ein Client-Knoten oder ein Server-Knoten ist, wobei die Client-Knoten die atomare Operation durchführen, indem sie in einem ersten zugewiesenen Teil, der auf dem neuen Wert und dem Offset basiert, an ein gemeinsames Objekt anhängen, das dem einen oder den mehreren Bits entspricht, wobei auf den gemeinsam genutzten entfernten Speicherinhalt durch ein mit dem verteilten System verbundenes Dateisystem zugegriffen wird, wobei das Dateisystem ein Fabric Attached Memory Filesystem (FAMfs) ist, wobei die Serverknoten E/A-Knoten in den FAMfs sind, wobei die Zuweisung der mehreren Speicherabschnitte durch Zuweisungsmodule erfolgt, die mit jedem E/A-Knoten in den FAMfs verbunden sind, und wobei der Inhalt des gemeinsam genutzten Fernspeichers eine Bitmap-Datenstruktur umfasst, die einen Status, wie verwendet oder frei, von physischen Ausmaßen im Speicher der FAMfs verfolgt.
  16. Das Computersystem nach Anspruch 15, wobei der gemeinsam genutzte Fernspeicherinhalt ein Inhaltsverzeichnis für Dateien und ein oder mehrere Zählerarrays umfasst, wobei die zugewiesenen Speicherabschnitte Partitionen des Inhaltsverzeichnisses und des einen oder der mehreren Zählerarrays umfassen, und wobei die Einträge, die den Dateien im Inhaltsverzeichnis entsprechen, umfassen: eine Referenzzahl, die die Anzahl der Prozesse angibt, die derzeit eine entsprechende Datei geöffnet haben; und ein Offset zu einem Element in einem der Zähler-Arrays.
  17. Das Computersystem nach Anspruch 16, wobei das Verfahren weiterhin umfasst: Empfang einer Anforderung zum Öffnen einer Datei mit einem zugehörigen Dateibezeichner in dem verteilten System; Bestimmung einer Partition des Inhaltsverzeichnisses, die den Dateibezeichner enthält; Beschaffung eines Spinlocks für die Partition des Inhaltsverzeichnisses; Durchsuchen der Partition des Inhaltsverzeichnisses, um einen Eintrag zu erhalten, der der Dateikennung entspricht, wobei der Eintrag umfasst: eine erste Referenzzahl; und einen ersten Versatz zu einem Element in einem ersten Zähler-Array, wobei das Element einen Zählwert einer mit dem Dateibezeichner verbundenen Aktion umfasst; Als Reaktion auf das Auffinden des Eintrags wird der erste Referenzwert erhöht; Freigabe des Spinlocks für die Partition des Inhaltsverzeichnisses; und Zugriff auf das erste Zählerfeld beim ersten Offset, um den Zählerstand der Aktion zu erhöhen.
  18. Das Computersystem nach Anspruch 15, wobei der entfernte gemeinsame Speicherinhalt eine globale Ringpuffer-Warteschlange umfasst, wobei die zugewiesenen Speicherabschnitte Segmente der globalen Ringpuffer-Warteschlange umfassen, und wobei ein jeweiliges Segment umfasst: eine Warteschlange, in der Daten, einschließlich Nachrichten, gespeichert werden können; einen Eingangssemaphor und einen Ausgangssemaphor, um den Zugriff auf die Warteschlange zu synchronisieren; und einen Eingabezeiger und einen Ausgabezeiger, um Positionen zu verfolgen, die sich auf Einfüge- und Entnahmevorgänge in der Warteschlange beziehen.
  19. Das Computersystem nach Anspruch 18, wobei das Verfahren ferner umfasst, dass der erste Client-Knoten auf das jeweilige Segment zugreift, indem er: Erfassen des Eingangssemaphors durch Dekrementieren des Eingangssemaphors; als Reaktion auf die erfolgreiche Erfassung des Eingangssemaphors, Inkrementieren des Eingangszeigers; Senden von Daten über RDMA an eine Speicherstelle, auf die der Eingabezeiger zeigt; und Freigabe des Ausgangssemaphors durch Inkrementierung des Ausgangssemaphors.
  20. Ein nicht-transitorisches, computerlesbares Speichermedium, das Befehle speichert, die, wenn sie von einem Computer ausgeführt werden, den Computer veranlassen, ein Verfahren durchzuführen, wobei das Verfahren umfasst: Zuteilung einer Vielzahl von Speicherabschnitten in einem verteilten System, das eine Vielzahl von Knoten umfasst, die einen gemeinsamen entfernten Speicherinhalt umfassen; Registrierung der zugewiesenen Teile bei einem Betriebssystem für den Zugriff über direkten Fernspeicherzugriff (RDMA); Zugreifen auf die zugewiesenen Teile durch einen ersten Knoten, um eine lokale Kopie des gemeinsamen entfernten Speicherinhalts zu erhalten; und Durchführung einer atomaren Operation an einem oder mehreren Bits des gemeinsam genutzten entfernten Speicherinhalts über libfabric atomic (LFA) Application Programming Interface (API)-Aufrufe, die eines oder mehrere der folgenden Elemente umfassen: Aktualisieren des einen oder der mehreren Bits des gemeinsamen Fernspeicherinhalts auf der Grundlage eines neuen Werts und eines Offsets; Abrufen eines aktuellen Wertes des einen oder der mehreren Bits aus dem gemeinsamen entfernten Speicherinhalt auf der Grundlage des Offsets vor der Aktualisierung; und Durchführen einer Aktion an dem gemeinsam genutzten entfernten Speicherinhalt auf der Grundlage eines Vergleichs des abgerufenen aktuellen Werts mit einem erwarteten Wert auf der lokalen Kopie.
DE102021127151.7A 2021-06-29 2021-10-20 Verfahren und system für libfabric atomics-basierte lockless cluster-wide shared memory access api in einem verteilten system Pending DE102021127151A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US17/362,587 US20220413743A1 (en) 2021-06-29 2021-06-29 Method and system for libfabric atomics-based lockless cluster-wide shared memory access api in a distributed system
US17/362,587 2021-06-29

Publications (1)

Publication Number Publication Date
DE102021127151A1 true DE102021127151A1 (de) 2022-12-29

Family

ID=84388636

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102021127151.7A Pending DE102021127151A1 (de) 2021-06-29 2021-10-20 Verfahren und system für libfabric atomics-basierte lockless cluster-wide shared memory access api in einem verteilten system

Country Status (3)

Country Link
US (1) US20220413743A1 (de)
CN (1) CN115543952A (de)
DE (1) DE102021127151A1 (de)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11669471B2 (en) * 2021-10-21 2023-06-06 EMC IP Holding Company, LLC System and method for lockless aborting of input/output (IO) commands
TWI769111B (zh) * 2021-11-17 2022-06-21 瑞昱半導體股份有限公司 基本儲存單元管理電路以及基本儲存單元管理方法

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9471323B2 (en) * 2013-10-03 2016-10-18 Intel Corporation System and method of using an atomic data buffer to bypass a memory location
US9875182B1 (en) * 2015-05-26 2018-01-23 EMC IP Holding Company LLC Lock free container packing
US10148570B2 (en) * 2015-12-29 2018-12-04 Amazon Technologies, Inc. Connectionless reliable transport
US20220114098A1 (en) * 2021-12-22 2022-04-14 Intel Corporation System, apparatus and methods for performing shared memory operations

Also Published As

Publication number Publication date
US20220413743A1 (en) 2022-12-29
CN115543952A (zh) 2022-12-30

Similar Documents

Publication Publication Date Title
US11663187B2 (en) Key-value store system
DE69838367T2 (de) Paralleles Dateiensystem und Verfahren zur unabhängigen Aufzeichnung von Metadaten
DE3854384T2 (de) Verfahren zum Betreiben eines einen anteilig genutzten virtuellen Speicher verwendenden Multiprozessorsystems.
DE3853460T2 (de) Raumverwaltungsanordnung für das Datenzugriffssystem eines Dateizugriffsprozessors.
DE102011076895B4 (de) Cachekohärenzprotokoll für persistente Speicher
US9208191B2 (en) Lock-free, scalable read access to shared data structures
US9684682B2 (en) Sharding of in-memory objects across NUMA nodes
US8930669B2 (en) Tiered data management method and system for high performance data monitoring
DE102013204521B4 (de) Transaktionsverwaltung für Datenbanksysteme
US6457021B1 (en) In-memory database system
DE60130420T2 (de) Vorrichtung und Verfahren zur Aufrechterhaltung einer verknüpften Liste
US6389513B1 (en) Disk block cache management for a distributed shared memory computer system
US10067974B2 (en) Loading and reloading an in-memory copy of a database object without blocking concurrent updates to the database object
Kejriwal et al. {SLIK}: Scalable {Low-Latency} Indexes for a {Key-Value} Store
DE102021127151A1 (de) Verfahren und system für libfabric atomics-basierte lockless cluster-wide shared memory access api in einem verteilten system
EP1168182B1 (de) Transientspeichersegmentsubsystem für ein paralleles Datenbanksystem
DE102013209350A1 (de) Ressource-Management-Subsystem, welches Fairness und Ordnung einhält
DE10219621A1 (de) Schnelle Prioritätsbestimmungsschaltung mit rotierender Priorität
DE10219623A1 (de) System und Verfahren zur Speicherentscheidung unter Verwendung von mehreren Warteschlangen
DE112014002754T5 (de) Effiziente Aufgabenplanung unter Verwendung eines Sperrmechanismus
DE102021108963A1 (de) Sperrenfreier arbeitseinsatz thread scheduler
US10082978B2 (en) Distributed shared log storage system having an adapter for heterogenous big data workloads
US8341368B2 (en) Automatic reallocation of structured external storage structures
DE60006121T2 (de) System und verfahren zum synchronisieren von datenkopien in einem rechnersystem
US11423003B2 (en) Optimistic concurrency control for database transactions

Legal Events

Date Code Title Description
R081 Change of applicant/patentee

Owner name: HEWLETT PACKARD ENTERPRISE DEVELOPMENT LP, SPR, US

Free format text: FORMER OWNER: HEWLETT PACKARD ENTERPRISE DEVELOPMENT LP, HOUSTON, TX, US

R082 Change of representative

Representative=s name: FLEUCHAUS & GALLO PARTNERSCHAFT MBB - PATENT- , DE

Representative=s name: FLEUCHAUS & GALLO PARTNERSCHAFT MBB PATENTANWA, DE