DE102019112291A1

DE102019112291A1 - Verbessertes speicherungsmodell für ein computersystem mit persistentem systemspeicher

Info

Publication number: DE102019112291A1
Application number: DE102019112291.0A
Authority: DE
Inventors: Dale Juenemann; James Boyd
Original assignee: Intel Corp
Current assignee: Intel Corp
Priority date: 2018-06-12
Filing date: 2019-05-10
Publication date: 2019-12-12
Also published as: CN110597742A; US20190042415A1

Abstract

Es wird ein Prozessor beschrieben. Der Prozessor umfasst Registerplatz zum Annehmen von Eingangsparametern eines Softwarebefehls zum Verlagern eines Datenpostens aus Computer-Systemspeicherung heraus und in persistenten Systemspeicher. Die Eingangsparameter umfassen eine Kennung eines Softwareprozesses, der Zugriff auf den Datenposten im persistenten Systemspeicher wünscht, und eine virtuelle Adresse des Datenpostens, auf die sich der Softwareprozess bezieht.

Description

Technisches Gebiet
Das Gebiet der Erfindung betrifft allgemein Computersystementwurf und insbesondere ein verbessertes Speicherungsmodell für ein Computersystem mit persistentem Systemspeicher.
Stand der Technik
Computersystementwickler sind hochmotiviert, die Leistungsfähigkeit der Computer, die sie entwickeln, zu steigern. Computer enthielten traditionell Systemspeicher und nichtflüchtige Massenspeicherung, die im Wesentlichen getrennte und isolierte Hardwarekomponenten des Systems waren. Neuere Fortschritte bei der nichtflüchtigen Speichertechnologie und Systemarchitektur haben es jedoch gestattet, dass Systemspeicher beginnt, Systemrollen anzunehmen, mit denen traditionell nichtflüchtige Massenspeicherung umgegangen ist.
Figurenliste
Aus der folgenden ausführlichen Beschreibung in Verbindung mit den folgenden Zeichnungen lässt sich ein besseres Verständnis der vorliegenden Erfindung erhalten. Es zeigen:

1 einen Systemspeicher mit zwei Ebenen;
2a und 2b zwei Speicherungsmodelle, die mit einem System mit persistentem Systemspeicher verwendet werden können;
3 ein verbessertes Speicherungsmodell, das mit einem System mit persistentem Systemspeicher verwendet werden kann;
4 ein Verfahren zum Emulieren des DAX-Modus auf einem System mit persistentem Systemspeicher, das ein traditionelles Dateisystem-Speicherungsmodell implementiert;
5 ein Datenverarbeitungssystem, mit dem das verbesserte Speicherungsmodell von 3 implementiert werden kann.

Ausführliche Beschreibung
1 zeigt eine Ausführungsform eines Datenverarbeitungssystems 100 mit einem mehrstufigen oder Mehrebenen-Systemspeicher 112. Gemäß verschiedenen Ausführungsformen kann ein kleinerer, schnellerer Nahspeicher 113 als Cache für einen größeren, langsameren Fernspeicher 114 benutzt werden. Bei verschiedenen Ausführungsformen dient der Nahspeicher 113 zum Speichern der Posten von Programmcode und/oder Daten, die im Systemspeicher 112 gehalten werden, auf die häufiger zugegriffen wird. Indem häufiger benutzte Posten im Nahspeicher 113 gespeichert werden, wird der Systemspeicher 112 als schneller beobachtet, weil das System oft aus/an Posten, die in dem schnelleren Nahspeicher 113 gespeichert sind, lesen/schreiben wird.
Gemäß verschiedenen Ausführungsformen weist der Nahspeicher 113 kleinere Zugriffszeiten als der auf niedrigerer Stufe befindliche Fernspeicher 114 auf. Zum Beispiel kann der Nahspeicher 113 verringerte Zugriffszeiten aufweisen, indem er eine schnellere Taktgeschwindigkeit als der Fernspeicher 114 aufweist. Der Nahspeicher 113 kann hier (z.B. niedrigere Zugriffszeit) flüchtige Systemspeichertechnologie sein schnellere (z.B. hochleistungsfähiger dynamischer Direktzugriffsspeicher (DRAM) und/oder SRAM-Speicherzellen), die zusammen mit dem Speichercontroller 116 angeordnet ist. Im Gegensatz dazu kann der Fernspeicher 114 nichtflüchtige Speichertechnologie sein, die langsamer ist (z.B. die längere Zugriffszeit) als flüchtiger/DRAM-Speicher oder jedwede Technologie, die für Nahspeicher verwendet wird.
Zum Beispiel kann der Fernspeicher 114 aus einer aufkommenden nichtflüchtigen Direktzugriffsspeichertechnologie bestehen, wie etwa, um nur einige wenige Möglichkeiten zu nennen, einem auf Phasenänderung basierenden Speicher, einem dreidimensionalen Kreuzpunktspeicher, nichtflüchtigen Hauptspeichervorrichtungen des Typs „Write-in-Place“, Speichervorrichtungen mit aus Chalkogenid zusammengesetzten Speicherungszellen, Mehrpegel-Flash-Speicher, Mehrschwellenpegel-Flash-Speicher, einen Speicher auf ferroelektrischer Basis (z.B. FRAM), einem Speicher auf magnetischer Basis (z.B. MRAM), einem auf Spin-Transfer-Torque basierenden Speicher (z.B. STT-RAM), einem Speicher auf Widerstandsbasis (z.B. ReRAM), einem Speicher auf Memristorbasis, Universalspeicher, Ge2Sb2Te5-Speicher, Speicher mit programmierbaren Metallisierungszellen, Speicher mit amorphen Zellen, Ovshinsky-Speicher usw. Jede dieser Technologien kann byteadressierbar sein, um so als Systemspeicher in einem Datenverarbeitungssystem (auch als „Hauptspeicher“ bezeichnet) implementiert zu werden, statt als traditionelle nichtflüchtige Massenspeicherung auf Block- oder Sektorbasis.
Aufkommende nichtflüchtige Direktzugriffsspeichertechnologien weisen typischerweise eine gewisse Kombination von Folgendem auf: 1) höhere Speicherungsdichten als DRAM (z.B. indem sie in dreidimensionalen (3D-) Schaltungsstrukturen (z.B. einer Kreuzpunkt-3D-Schaltungsstruktur) konstruiert sind); 2) geringere Stromverbrauchsdichten als DRAM im Leerlauf (z.B. weil sie kein Auffrischen benötigen); und/oder 3) Zugriffslatenz, die langsamer als DRAM aber immer noch schneller als traditionelle nichtflüchtige Speichertechnologien wie Flash ist. Die letztere Eigenschaft gestattet insbesondere die Verwendung von verschiedenen aufkommenden nichtflüchtigen Speichertechnologien in einer Hauptsystemspeicherrolle, statt einer traditionellen Massenspeicherungsrolle (die der traditionelle Architekturort von nichtflüchtiger Speicherung ist).
Bei verschiedenen Ausführungsformen wirkt der Fernspeicher 114 insofern als echter Systemspeicher, als er feinkörnigere Datenzugriffe (z.B. Cache-Linien) unterstützt, statt nur „Block“- oder „Sektor“-Zugriffe auf größerer Basis, die traditioneller nichtflüchtiger Massenspeicherung (z.B. Halbleiterlaufwerk (SSD), Festplattenlaufwerk (HDD)) zugeordnet sind, und/oder wirkt ansonsten als byteadressierbarer Speicher, aus dem der Programmcode, der durch Prozessor(en) der CPU ausgeführt wird, operiert.
Bei verschiedenen Ausführungsformen kann Systemspeicher mit DIMM-Karten (Dual In-Line Memory Module) implementiert werden, wobei auf einer einzelnen DIMM-Karte sowohl flüchtige (z.B. DRAM-) als auch (z.B. aufkommende) nichtflüchtige Speicher-Halbleiterchips angeordnet sind. In anderen Konfigurationen können DIMM-Karten, die nur DRAM-Chips aufweisen, in einen selben Systemspeicherkanal (z.B. einen Doppeldatenraten- bzw. DDR-Kanal) eingesteckt werden, mit DIMM-Karten, die nur nichtflüchtige Systemspeicherchips aufweisen.
In einer anderen möglichen Konfiguration kann eine Speichervorrichtung, wie etwa eine DRAM-Vorrichtung, die als Nahspeicher 113 fungiert, zusammen mit dem Speichercontroller 116 und Verarbeitungskernen 117 auf einer einzigen Halbleitervorrichtung (z.B. als eingebetteter DRAM) oder in einer selben Halbleiterkapselung (z.B. gestapelt auf einem System auf einem Chip, das z.B. die CPU, den Speichercontroller, einen Peripherie-Steuerhub usw. enthält) zusammengebaut werden. Der Fernspeicher 114 kann durch andere Vorrichtungen gebildet werden, wie etwa aufkommenden nichtflüchtigen Speicher, und kann auch an dieselbe Kapselung angeschlossen oder in dieser integriert werden. Als Alternative kann sich Fernspeicher außerhalb einer Kapselung befinden, die die CPU-Kerne und Nahspeichervorrichtungen enthält. Ein Fernspeichercontroller kann auch zwischen dem Hauptspeichercontroller und Fernspeichervorrichtungen existieren. Der Fernspeichercontroller kann in eine selbe Halbleiterchipkapselung wie CPU-Kerne und ein Hauptspeichercontroller integriert werden oder kann außerhalb solch einer Kapselung angeordnet werden (z.B. indem er auf eine DIMM-Karte mit Fernspeichervorrichtungen integriert wird).
Bei verschiedenen Ausführungsformen weist mindestens ein gewisser Teil des Nahspeichers 113 seinen eigenen Systemadressenraum auf, neben den Systemadressen, die Speicherstellen des Fernspeichers 114 zugewiesen wurden. In diesem Fall wirkt der Teil des Nahspeichers 113, dem sein eigener Systemspeicher-Adressenraum zugeteilt wurde, z.B. als eine höhere Prioritätsebene des Systemspeichers (weil er schneller als Fernspeicher ist). Bei weiteren Ausführungsformen kann ein bestimmter anderer Teil des Nahspeichers 113 auch als Speicher-Seitencache (der die Posten aus dem Hauptspeicher (der mehr als nur den CPU-Kern bzw. die CPU-Kerne versorgen kann, wie etwa eine GPU, ein Peripheriegerät, eine Netzwerkschnittstelle, Massenspeichervorrichtungen usw.), auf die am häufigsten zugegriffen wird, zwischenspeichert) oder als CPU-Cache der letzten Ebene (der nur CPU-Kern(e) versorgt) wirken.
Da der Fernspeicher 113 nichtflüchtig ist, kann er auch als „persistenter Speicher“, „persistenter Systemspeicher“ und dergleichen bezeichnet werden, weil seine nichtflüchtige Beschaffenheit bedeutet, dass seine Daten „persistieren“ (nicht verlorengehen), selbst wenn die Stromversorgung entfernt wird.
2a und 2b zeigen jeweils zwei Systemspeicherungsmodelle 200, 210, die in einem System verwendet werden können, das persistente Systemspeicherressourcen aufweist. Gemäß dem ersten Modell 200 von 2a, das als Direktzugriffs- bzw. DAX-Modus bezeichnet wird, erreicht Anwendungssoftware 201 (z.B. Speicherungsanwendungssoftware) Datenposten, die in dem nichtflüchtigen persistenten Speicher gespeichert wurden, mittels eines Speicherungs-Kernel 202 auf niedriger Ebene. Der Speicherungs-Kernel 202 auf niedriger Ebene kann eine oder mehrere Komponenten von Software auf niedriger Ebene sein, wie etwa eine oder mehrere Komponenten eines Betriebssystem- bzw. OS-Kernel, eines VMM (Virtual Machine Monitor) und/oder eines Massenspeicherungs-Hardwaregerätetreibers, die eine Softwareplattform „unter“ der Anwendungssoftware 201 bilden. Der Speicherungs-Kernel 202 auf niedriger Ebene kann z.B. byteadressierbare Lade-/Speicheroperationen direkt aus nichtflüchtigen (persistenten) Speicherressourcen des Systemspeichers 203 heraus ausführen.
Traditionelle Datenverarbeitungssysteme haben es Speicherungsanwendungen oder anderen Softwareprozessen, die „Verpflichtung“ (oder andere Formen einer nichtflüchtigen Garantie, dass Daten nicht verloren würden) erforderten, ermöglicht, aus flüchtigem DRAM-Systemspeicher heraus zu operieren. Um jedoch sicherzustellen, dass Daten als Folge der flüchtigen Beschaffenheit von DRAM nicht verloren würden, folgte jeglicher Speicher-(Schreib-)Operation in DRAM-Systemspeicher automatisch ein „Kopier“-Schreiben der Daten in eine tiefere nichtflüchtige Massenspeicherung (z.B. Festplatte (HDD), Halbleiterlaufwerk-/Vorrichtung (SSD) usw.). Dementsprechend wurde jegliche Verbesserung der Leistungsfähigkeit, die erhalten wurde, indem es solcher Software gestattet wird, aus DRAM-Systemspeicher heraus zu operieren, bis zu einem gewissem Grade durch den zusätzlichen internen Verkehr ausgeglichen, der aus der Kopieroperation (die manchmal auch als „Copy-on-Write“-Operation bezeichnet wird) erzeugt wird.
Das DAX-Modell 200 umfasst keinerlei Kopieroperation in tiefere Massenspeicherung, weil das Modell versteht, dass die Daten in persistenten Speicher geschrieben werden und deshalb nicht automatisch gesichert werden müssen. Folglich repräsentiert das DAX-Modell 200 vom Standpunkt des Garantierens, dass Daten nicht verloren gehen, einen idealen Betriebsmodus, während gleichzeitig interner Verkehr in dem Datenverarbeitungssystem minimiert wird.
Wenn insbesondere deshalb die Speicherungskapazität des persistenten Speichers ausreicht, um den nichtflüchtigen Speicherungsbedürfnissen des gesamten Datenverarbeitungssystems zu genügen (was z.B. Speicherung des gesamten Betriebssystem-Softwareprogrammcodes, Speicherung des gesamten Anwendungssoftware-Programmcodes und zugeordneter Daten usw. erfordert), ist es denkbar, dass das Datenverarbeitungssystem keinerlei traditionelle Massenspeicherungsvorrichtungen benötigt. Das heißt, der persistente Speicher macht, obwohl er formal eine Komponente des Systemspeichers ist, tiefere nichtflüchtige Massenspeicherung aufgrund seiner nichtflüchtigen Beschaffenheit überflüssig.
Leider umfassen einige Systeme, wie etwa Client-Vorrichtungen mit geringerer Leistungsfähigkeit (z.B. Desktop-Computer, Laptop-Computer, batteriebetriebene in der Hand gehaltene Vorrichtungen (z.B. Smartphones), intelligente Geräte (Vorrichtungen des Internet der Dinge (IoT) usw.) möglicherweise nicht genug persistenten Speicher, um tiefere Massenspeicherung völlig überflüssig zu machen. Solche Systeme umfassen deshalb eine oder mehrere tiefere Massenspeicherungsvorrichtungen, so dass die gesamte Menge Systemsoftware und andere kritische Informationen permanent durch das System behalten werden kann, selbst wenn die Stromversorgung entfernt wird.
Da solche Systeme dazu gezwungen werden, tiefere Massenspeicherungsvorrichtung(en) zu enthalten, werden sie leider auch dazu gezwungen, ein oben angedeutetes Modell des traditionellen Dateisystems (TFS) zu verwenden. Das heißt, Speicherungssoftware oder andere Softwareprozesse, die garantieren müssen, dass ihre Daten nicht verloren gehen, dürfen Daten in einen Massenspeicherungs-Cache 214 in dem Systemspeicher 213 schreiben (wozu Schreiben z.B. in eine flüchtige DRAM-Nahspeicherebene und/oder eine nichtflüchtige persistente Speicherebene gehören kann).
Solche Daten, die in den Massenspeicherungs-Cache 214 geschrieben werden, werden jedoch automatisch mittels einer Copy-on-Write-Operation in die Massenspeicherung 215 zurückgeschrieben - selbst wenn solche Daten in persistente Systemspeicherressourcen geschrieben werden. Gleichgültig, ob Daten in eine DRAM-Ebene des Systemspeichers oder eine nichtflüchtige Ebene des Systemspeichers geschrieben werden, wird hierbei der Systemspeicher 213 als Ganzes als Cache 214 für die Massenspeicherung 215 angesehen, deren Zustand zurück in Massenspeicherung verpflichtet werden muss, um sichere Aufbewahrung von Daten und/oder Stimmigkeit von Daten im System zu garantieren. Der Effizienzvorteil des DAX-Modells (Beseitigung von internem Kopierverkehr) geht dementsprechend verloren, wenn einem Computersystem, das nichtflüchtigen Systemspeicher aufweist, das TFS-Modell 210 auferlegt wird.
Ein neues Modell, das die Implementierung des traditionellen Copy-on-Write-Modells im System nicht verletzt, und dennoch die Copy-on-Write-Operation vermeidet, wenn Software in nichtflüchtigen Systemspeicher schreibt, wäre nützlich, weil der Effizienzvorteil des DAX-Modells effektiv in dem System realisiert werden könnte, obwohl das System das DAX-Modell formal nicht implementiert.
3 zeigt eine Ausführungsform eines solchen Modells 300, das hier als das Modell der „DAX-Emulation“ bezeichnet wird). Wie in 3 zu sehen ist, wird vorausgesetzt, dass das System einen Mehrebenen-Systemspeicher umfasst, indem ein bestimmter Teil der flüchtigen DRAM-Ebene und/oder der nichtflüchtigen persistenten/Fernspeicherebene als Massenspeicherungs-Cache 314 benutzt wird. Wenn Anwendungsdaten in den Massenspeicherungs-Cache 314 geschrieben werden, werden die Daten formal als eine Copy-on-Write-Operation in die Massenspeicherung 315 zurückgeschrieben. Dementsprechend wird das traditionelle Dateisystem formal anerkannt und existiert betriebsmäßig im Computer.
Bei verschiedenen Ausführungsformen kann Anwendungssoftware 311 (wie etwa eine Speicherungsanwendung) verstehen/erkennen, wann sie in die „Massenspeicherung“ 315 (oder einfach „Speicherung“ 315) des Systems schreibt. Der Speicherungs-Kernel 312 auf niedrigerer Ebene kann einen Massenspeicherungs-Cache 314 in dem Systemspeicher 313 bewirken oder anderweitig zu dessen Implementierung ausgelegt werden, indem z.B. „Speicherungs“-Schreibvorgänge von der Anwendungssoftware 311 auf den Massenspeicherungs-Cache 314 gelenkt werden, der im Systemspeicher residiert, gefolgt von einer Copy-on-Write-Operation der Schreibdaten in die Massenspeicherung 315. Dementsprechend werden „Speicherungs“-Schreibvorgänge formal von dem System gemäß dem TFS-Modell ausgeführt.
In dem verbesserten Modell 300 von 3 ist die Anwendungssoftware 311 jedoch intelligent genug, um zu verstehen, dass es persistente Systemspeicherressourcen in dem System gibt, und kann deshalb anfordern, dass Daten, die in der Massenspeicherung des Systems gespeichert sind (z.B. eine Daten-Datei) in den Systemspeicher-Adressenraum des persistenten Systemspeichers abgebildet werden. Während die Massenspeicherungsregion 314 hier beispielsweise einer Region von Systemspeicher entspricht, die dafür ausgelegt ist, sich als Massenspeicherungs-Cache zu verhalten (und eine oder beide Ebenen eines Mehrebenen-Systemspeichers umfassen kann) und dessen Inhalte deshalb in Massenspeicherung zurückkopiert werden müssen, entspricht hier dagegen die Region 316 tatsächlichem Systemspeicher mit zuteilbaren Systemspeicher-Adressenraum.
Wenn die Anwendungssoftware 311 intelligent genug ist, die Existenz von nichtflüchtigem Systemspeicher 316 im System zu erkennen, gibt die Anwendungssoftware 311 formal eine Anforderung an das Speicherungssystem z.B. über den Speicherungs-Kernel 313 auf niedriger Ebene aus, um eine Datei oder einen anderen Datenposten in der Massenspeicherung 314, 315 „freizugeben“ und ihn in eine persistente Region des Systemspeichers 316 einzugeben. Gemäß einem Ansatz wird, wenn die letzte Version des Datenpostens bereits in dem Massenspeicherungs-Cache 314 existiert, der Datenposten physisch aus der Massenspeicherungs-Cache-Region 314 in die persistente Systemspeicherregion verlagert. Wenn die letzte Version des Datenpostens bereits in nichtflüchtigen Ressourcen des Massenspeicherungs-Cache 314 existiert (z.B. in einem persistenten Speicherteil des Massenspeicherungs-Cache 314 residiert), wird als Alternative seine aktuelle Adresse im persistenten Speicher von der Assoziation mit dem Massenspeicherungs-Cache 314 auf die Assoziation mit Systemspeicher umgewechselt. Wenn der Datenposten nicht in dem Massenspeicherungs-Cache 314 existiert, wird er aus der Massenspeicherung 315 aufgerufen und in eine Region des persistenten Systemspeichers 316 eingegeben.
Nachdem das Speicherungssystem die Anforderung voll verarbeitet, residiert dessen ungeachtet der Datenposten in einer nichtflüchtigen Region des Systemspeichers 316, statt in dem „Speicherungs“-Subsystem des Systems (obwohl aus Sicherheitsgründen eine Duplikatkopie in der Speicherung gehalten werden kann). Wenn die Anwendung 311 danach in den Datenposten schreibt, versteht sie, dass sie nicht in „Speicherung“ schreibt, sondern stattdessen im DAX-Emulationsmodus in „Systemspeicher“ schreibt. Wie oben angedeutet kann die Anwendung 311 intelligent genug sein, zu verstehen, dass die Region 316 des Systemspeichers, in die geschrieben wird, nichtflüchtig ist, und deshalb die Sicherheit der Daten garantiert ist. Wichtig ist jedoch, dass, weil die Schreibdaten in eine nichtflüchtige Region 316 des Systemspeichers (und nicht in „Speicherung“) geschrieben werden, keine Copy-on-Write-Operation in Massenspeicherung als Reaktion auf Schreiboperationen, die an den Datenposten in der nichtflüchtigen Region 316 des Systemspeichers ausgeführt werden, erforderlich ist oder ausgeführt wird. Nach dem Verarbeiten der Anforderung emuliert dementsprechend das System effektiv DAX-Betrieb, obwohl das DAX-Modell im System nicht formal anerkannt wird.
Die oben beschriebene Semantik kann besonders nützlich sein, wenn z.B. die Anwendungssoftware 311 erkennt oder anderweitig vorhersagt, dass sie einen bestimmten Datenposten unmittelbar bevorstehend aktualisieren (oder noch besser unmittelbar bevorstehend und häufig aktualisieren) wird. Die Anwendung fordert von dem Massenspeicherungssystem deshalb an, den Datenposten freizugeben und ihn auf persistenten Systemspeicher 316 abzubilden. Die Anwendung 311 kann dann weiter viele häufige Aktualisierungen an dem Datenposten in dem persistenten Systemspeicher 316 ausführen. Da kein Copy-on-Write durchgeführt wird, wird die Ineffizienz des Kopierens jeder Schreiboperation zurück in Massenspeicherung 315 vermieden, um dadurch die Gesamteffizienz des Systems zu verbessern. Nachdem die Anwendung 311 glaubt/vorhersagt, dass ihre Aktualisierung des Datenpostens beendet ist, z.B. für den Moment, kann sie den Datenposten in „Speicherung“ schreiben, so dass z.B. der von dem Datenposten in dem persistenten Systemspeicher 316 verbrauchte Platz für einen anderen Datenposten aus der Speicherung verwendet werden kann.
4 zeigt eine ausführlichere Ausführungsform einer Methodologie, durch die eine Anwendung von Systemspeicherung anfordert, einen Posten von Daten freizugeben und den Datenposten dann auf persistenten Systemspeicher abzubilden.
Wie in der Technik bekannt ist, werden einer Softwareanwendung typischerweise ein oder mehrere Software-„Threads“ (die auch als „Prozesse“ bezeichnet werden) zugeteilt, die auf Zentralverarbeitungseinheit- bzw. CPU-Hardwareressourcen ausgeführt werden. Außerdem wird Softwareanwendungen und den zur Ausführung dieser verwendeten Threads typischerweise eine gewisse Menge Systemspeicher-Adressenraum zugeteilt. Der tatsächliche Programmcode der Anwendung ruft „virtuelle“ Systemspeicheradressen auf, wenn Systemspeicher für Programmcodelesevorgänge oder Datenlesevorgänge und Datenschreibvorgänge aktiviert wird. Zum Beispiel kann sich der Programmcode aller Anwendungen auf dem Computersystem auf einen Systemspeicher-Adressenbereich beziehen, der an der Adresse 000...0 startet. Der Wert jeder nächsten Speicheradresse, auf die sich die Anwendung bezieht, wird um +1 inkrementiert, bis ein Adressenwert erreicht ist, der der letztendlichen Menge an Systemspeicher-Adressenraum entspricht, die die Anwendung benötigt (dementsprechend entspricht die Menge an Systemspeicher-Adressenraum, die von der Anwendung benötigt wird, ihrem virtuellen Adressenbereich).
Der Computer vergibt jedoch z.B. mittels der Prozessorhardware und des Betriebssystems, auf dem die Anwendung betrieben wird (und/oder eines Virtual Machine Monitor, auf dem das Betriebssystem operiert) dynamisch physischen Systemspeicher-Adressenraum an die Anwendungen, die aktiv ausgeführt werden. Der dynamische Vergabeprozess umfasst Konfigurieren der Prozessorhardware (typischerweise eines TLB (Translation Look-Aside Buffer) in einer MMU (Memory Management Unit) der CPU) zur Übersetzung einer durch eine bestimmte Anwendung aufgerufenen virtuellen Adresse in eine bestimmte physische Adresse im Systemspeicher. Die Übersetzungsoperation umfasst typischerweise Addieren eines Offsetwerts zu der virtuellen Adresse der Anwendung.
Wie nachfolgend ausführlicher beschrieben wird, wird eine Anwendung typischerweise so geschrieben, dass sie sich auf „Seiten“ von Informationen in Systemspeicher bezieht. Eine Seite von Informationen entspricht typischerweise einem kleinen zusammenhängenden Bereich virtueller Adressen, worauf sich die Anwendung bezieht. Jede Seite von Informationen, die physisch im Systemspeicher für eine Anwendung zugeteilt werden kann, weist typischerweise ihren eigenen eindeutigen Eintrag im TLB mit entsprechendem Offset auf. Hierdurch muss nicht der gesamte Systemspeicher-Adressenraum, der der Anwendung zugeteilt wird, zusammenhängend sein. Stattdessen können die Seiten von Informationen über den Systemspeicher-Adressenraum verstreut sein.
Der TLB/die MMU wird deshalb durch das OS/den VMM so konfiguriert, dass er bzw. sie einen spezifischen Thread/Prozess (der die Anwendung identifiziert) und die durch den Thread/Prozess ausgerufene virtuelle Adresse mit einem spezifischen Offsetwert korreliert, der zu der virtuellen Adresse zu addieren ist. Das heißt, wenn eine bestimmte Anwendung eine Systemspeicher-Zugriffsanweisung ausführt, die eine bestimmte virtuelle Speicheradresse spezifiziert, verwendet der TLB die ID des Thread, der die Anwendung ausführt, und die virtuelle Adresse als Nachschlageparameter, um den korrekten Offsetwert zu erhalten. Die MMU addiert das Offset dann zu der virtuellen Adresse, um die korrekte physische Adresse zu bestimmen, und gibt eine Anforderung an den Systemspeicher mit der korrekten physischen Adresse aus.
Wie in 4 zu sehen ist, umfasst der DAX-Emulationsprozess, dass eine Anwendung 411 anfänglich von ihrem Massenspeicherungs-Kernel 412 anfordert 417, einen Datenposten aus dem Speicherungssystem freizugeben und ihn in nichtflüchtige Ressourcen 416 des Systemspeichers 413 einzugeben. Wie in der Technik bekannt ist, führt, wenn eine Anwendung auf das Speicherungs-Subsystem zugreift, sie hier einen Funktionsaufruf an ihren Massenspeicherungs-Kernel 412 durch. In dem DAX-Emulationsprozess von 4 sendet die Anwendung eine „Freigabeanforderung“ für einen spezifischen Datenposten (der z.B. durch seine virtuelle Adresse identifiziert wird) zu dem Massenspeicherungs-Kernel 412. Der Anforderung ist die ID des Threads zugeordnet, der die Anwendung 411 ausführt. Die Thread-ID kann als eine Variable mittels der Anwendungsprogrammierschnittstelle (API) des Kernels weitergeleitet werden oder kann durch den Kernel 412 über einen gewissen anderen Hintergrundmechanismus erhalten werden (wie etwa wenn die Anwendung ihre Thread-ID beim Kernel 412 registriert, wenn die Anwendung das erste Mal gebootet wird).
Wenn die Thread-ID und die virtuelle Adresse des spezifischen Datenpostens dem Massenspeicherungs-Kernel 412 bekannt sind, beginnt der Massenspeicherungs-Kernel 412 den Prozess des formalen Verlagerns des Datenpostens aus dem Speicherungssystem heraus in persistenten Systemspeicher 416. Wie in 4 zu sehen ist, fordert bei einer Ausführungsform der Kernel 412 eine „freie“ (unbenutzte) persistente Systemspeicheradresse von der Prozessor-MMU 419 oder anderer Hardware des Prozessors 420, die Kenntnisse darüber hat, welche persistenten Systemspeicheradressen aktuell nicht vergeben sind, an 418.
Teil der Anforderung 418 einer freien Systemspeicheradresse umfasst Weiterleiten der Thread-ID zur MMU 419. Die MMU 419 bestimmt eine physische Adresse in dem persistenten Systemspeicher 416, die dem Datenposten zugeteilt werden kann, und bestimmt auch eine entsprechende virtuelle Adresse, die bei der Bezugnahme auf den Datenposten zu verwenden ist. Die MMU 419 ist dann in der Lage, einen Eintrag für ihren TLB zu konstruieren, der sowohl die virtuelle Adresse, die bei der Bezugnahme auf den Datenposten zu verwenden ist, als auch die Thread-ID, die versuchen wird, auf sie zuzugreifen (die der Anwendung 411 entspricht, die die Anforderung gestellt hat) aufweist. Der Eintrag wird in den TLB eingegeben, um die geeignete Übersetzung von virtuellen in physische Adressen in der CPU-Hardware 421 „einzurichten“.
Die MMU 419 gibt dann sowohl die neu identifizierte virtuelle Adresse, die beim Versuchen, auf den Datenposten zuzugreifen, zu verwenden ist, als auch die physische Adresse im persistenten Systemspeicher 416, an die der Datenposten zu verlagern ist, an den Massenspeicherungs-Kernel 412 zurück 422. Mit Kenntnis der physischen Adresse des Systemspeichers, an die der Datenposten zu verlagern ist, wirkt der Massenspeicherungs-Kernel 412 dann zum Verlagern des Datenpostens an diesen Ort.
Wenn sich hierbei der Datenposten in der Massenspeicherungsvorrichtung 415 befindet, ruft der Massenspeicherungs-Kernel 412 den Datenposten aus der Massenspeicherung 415 auf und gibt ihn an der durch die MMU 419 zurückgegebenen physischen Adresse in den persistenten Speicher 416 ein.
Wenn sich dagegen der Datenposten in dem Massenspeicherungs-Cache 414 befindet, liest bei einer Ausführungsform der Massenspeicherungs-Kernel 412 den Datenposten aus dem Massenspeicherungs-Cache 414 und schreibt ihn an der neu zugeteilten physischen Adresse in den persistenten Systemspeicher 316. Bei einer alternativen Ausführungsform müssen die Systemspeicheradressen, die dem Massenspeicherungs-Cache 414 zugeteilt werden, nicht zusammenhängend sein. Systemspeicheradressen, die an den Massenspeicherungs-Cache 414 zugeteilt werden, werden hier dynamisch konfiguriert/umkonfiguriert und können deshalb über den Adressenraum des Systemspeichers 413 verstreut sein. Wenn der Massenspeicherungs-Cache 414 auf diese Weise implementiert wird und der aktuell interessierende Datenposten in einem persistenten Speicherteil des Massenspeicherungs-Cache 414 residiert, fordert der Massenspeicherungs-Kernel 412, statt den Datenposten physisch an einen neuen Ort zu verlagern, stattdessen von der MMU 419 an, einen speziellen TLB-Eintrag hinzuzufügen, der die virtuelle Adresse zum Zugreifen auf den Datenposten in die persistente Speicheradresse übersetzt, an der der Datenposten aktuell in dem Massenspeicherungs-Cache 314 residiert.
Die MMU 419 bestimmt die bei der Bezugnahme auf den Datenposten zu verwendende virtuelle Adresse und ist mit der durch den Massenspeicherungs-Kernel 412 bereitgestellten Thread-ID in der Lage, den TLB-Eintrag so zu konstruieren, dass seine Übersetzungen auf den aktuellen Ort des Datenpostens abgebildet werden. Die bei der Bezugnahme auf den Datenposten zu verwendende virtuelle Adresse wird dann zum Massenspeicherungs-Kernel 412 weitergeleitet 422. Wenn der TLB-Eintrag formal hinzugefügt wird und wirksam wird und der Massenspeicherungs-Kernel 412 genauso in der Lage ist, den Verlust seiner Massenspeicherungs-Cache-Adresse zu erkennen (z.B. durch Aktualisieren einer Tabelle, die die Systemspeicheradressen auflistet, die dem Massenspeicherungs-Cache entsprechen), wird der Ort im persistenten Speicher, an dem der Datenposten aktuell residiert, formal von einem Massenspeicherungs-Cache-Ort in einen persistenten Systemspeicherort konvertiert. Die Entfernung des Datenpostens aus dem Speicherungssystem und seine Eingabe in persistenten Systemspeicher wird dementsprechend erreicht, ohne den Datenposten physisch in den persistenten Speicher zu verlagern (er bleibt an derselben Stelle).
Man beachte, dass der „Datenposten“ tatsächlich einer oder mehreren Seiten von Informationen entsprechen kann. Wie in der Technik bekannt ist, umfasst das TFS-Modell hier die Eigenschaft, dass, während auf Systemspeicher physisch mit einem feinen Grad an Datengranularität (z.B. Cache-Linien-Granularität) zugegriffen wird, im Gegensatz dazu auf Massenspeicherung mit einem groben Grad an Datengranularität (z.B. so viel wie mehreren Cache-Linien Informationen, die einer oder mehreren „Seiten“ von Informationen entsprechen) zugegriffen wird. Dementsprechend werden Informationen im Allgemeinen aus der Massenspeicherung 415 in Systemspeicher 413 verlagert, indem eine oder mehrere Seiten von Informationen aus der Massenspeicherung 415 gelesen und die eine oder mehreren Seiten von Informationen in dem Systemspeicher 413 geschrieben werden.
Bei verschiedenen Ausführungsformen entspricht der „Datenposten“, dessen Entfernung aus dem Speicherungssystem und dessen Eingabe in persistenten Systemspeicher die Anwendung anfordert, der Adresse einer oder mehrerer Seiten von Informationen, wobei jede Seite mehrere Cache-Linien von Daten enthält. Die Anwendung 411 wünscht vermutlich DAX-Emulation für mindestens eine dieser Cache-Linien. Die „Freigabe“ des Datenpostens aus dem Speicherungssystem in persistentem Systemspeicher bringt dementsprechend tatsächlich die Freigabe einer oder mehrerer Seiten von Daten mit sich, statt nur so viel wie eine Cache-Linie Informationen.
Ferner beachte man, dass gemäß dem traditionellen Betrieb die MMU 419 oder andere Prozessorhardware dafür verantwortlich ist, zu erkennen, wann eine durch eine Anwendung aufgerufene virtuelle Adresse nicht einer Seite von Informationen entspricht, die aktuell im Systemspeicher 413 residiert. Als Reaktion auf diese Erkennung ruft die MMU 419 aus der Massenspeicherung 415 die Seite von Informationen auf, die die erwünschten Daten aufweist, und schreibt sie im Systemspeicher 413. Nachdem die Seite von Informationen in den Systemspeicher 413 geschrieben wurde, kann die Speicherzugriffsanforderung abgeschlossen werden. Das Hineinwechseln der Seite von Informationen aus der Massenspeicherung 415 kann auf Kosten des Herauswechselns einer anderen Seite der Informationen der Anwendung aus dem Systemspeicher 413 zurück in die Massenspeicherung 415 erfolgen. Ein solches Verhalten ist bei Anwendungen, denen weniger physischer Speicherplatz im Systemspeicher 413 als die Gesamtmenge von Seiten von Informationen, in die sie zur Bezugnahme geschrieben werden, zugeteilt wird, häufig.
Unabhängig davon, welcher Ansatz zur Entfernung des Datenpostens aus dem Speicherungssystem und seiner Eingabe in persistenten Systemspeicher verwendet wird (Aufrufen des Datenpostens aus Massenspeicherung, physisches Verlagern des Datenpostens aus Massenspeicherungs-Cache in persistenten Systemspeicher oder Umcharakterisierung des Orts des Datenpostens in persistenten Speicher von Massenspeicherungs-Cache in persistenten Systemspeicher), versteht der Massenspeicherungs-Kernel 412 letztendlich, wann der Datenposten formal außerhalb des Massenspeicherungssystems liegt, wann der Datenposten formal im persistenten Systemspeicher 416 liegt, und über die entsprechende virtuelle Adresse zur Verwendung bei der Bezugnahme auf den Datenposten im persistenten Systemspeicher 416 informiert wurde. An diesem Punkt schließt der Massenspeicherungs-Kernel 412 den Anforderungsprozess ab, indem die neue virtuelle Adresse der Anwendung 411 bereitgestellt 423 wird. Vorausschauend wird die Anwendung 411 diese virtuelle Adresse beim Versuch des Zugriffs auf den Datenposten direkt aus dem persistenten Systemspeicher 416 verwenden. Da der TLB-Eintrag bereits in die MMU 419 eingegeben wurde, wird die CPU-Hardware 421 den physischen Ort des Datenpostens im Systemspeicher 416 korrekt bestimmen.
Bei einer weiteren Ausführungsform existiert eine Anwendungssoftwareebenen-„Bibliothek“ 424, die im Wesentlichen verfolgt, welche Datenposten sich für emulierten DAX-Zugriff in persistentem Systemspeicher 416 befinden. Hier kann zum Beispiel ein selber Datenposten von mehreren verschiedenen Anwendungen verwendet werden, und die Bibliothek 424 wirkt als geteiltes/zentralisiertes Repositorium, das es mehr als einer Anwendung gestattet, zu verstehen, welche Datenposten für DAX-Emulationszugriff verfügbar sind.
Wenn zum Beispiel eine Anwendung anfordert, dass ein Datenposten formal aus dem Speicherungssystem entfernt und zur DAX-Emulation in persistenten Systemspeicher eingegeben wird, wird beim Abschluss der Anforderung die spezielle virtuelle Adresse, die zum Zugreifen auf den Datenposten zu verwenden ist, die durch den Massenspeicherungs-Kernel 412 zurückgegeben 423 wird, in die Bibliothek 424 eingegeben (z.B. zusammen mit einer bestimmten Kennung des Datenpostens, der von der Anwendung bzw. den Anwendungen verwendet wird). Sollte danach eine andere Anwendung Zugriff auf den Datenposten wünschen, kann die Anwendung zuerst bei der Bibliothek 424 anfragen. Als Reaktion bestätigt die Bibliothek 424, dass DAX-Emulation für den Datenposten verfügbar ist, und stellt der anderen Anwendung die virtuelle Adresse bereit, die für den Zugriff auf den Datenposten zu verwenden ist.
Wenn ähnlich eine Anwendung wünscht, einen Datenposten aus persistentem Systemspeicher 416 zu entfernen, kann sie zuerst die Bibliothek 424 benachrichtigen, die eine Aufzeichnung aller Anwendungen führt, die über denselben Datenposten angefragt haben und denen ihre virtuelle DAX-Emulationsadresse bereitgestellt wurde. Die Bibliothek 424 kann dann jeder solchen Anwendung ein Ping senden, um ihre Akzeptanz zu bestätigen, dass der Datenposten aus persistentem Systemspeicher 416 entfernt wird. Wenn alle (oder mindestens eine Mehrheit oder beschlussfähige Mehrheit) zustimmen, kann die Bibliothek 424 (oder die Anwendung, die seine Entfernung angefordert hat) anfordern, dass der Datenposten aus persistentem Systemspeicher entfernt und wieder in das Massenspeicherungssystem eingegeben wird (außerdem beachte man, dass die Bibliothek 424 als die zentrale Funktion zur Anforderung 417 von DAX-Emulation für einen bestimmten Datenposten wirken kann, statt einer Anwendung 411).
Das Wiedereingeben des Datenpostens in das Speicherungssystem aus persistentem Systemspeicher 416 kann durch beliebiges von Folgendem erreicht werden: 1) physisches Schreiben des Datenpostens zurück in die Massenspeicherung 415; 2) physisches Schreiben des Datenpostens zurück in den Massenspeicherungs-Cache 414; oder 3) Umcharakterisieren des Orts, an dem der Datenposten residiert, als Teil des Massenspeicherungs-Cache 414, statt als persistenten Systemspeicher 416. Dessen ungeachtet wird der spezielle Eintrag, der in der TLB für den DAX-Emulationszugriff auf den Datenposten erzeugt wurde, aus der TLB abgeworfen, so dass die Übersetzung von virtuelle in physische Adresse, die für den Datenposten im DAX-Emulationsmodus konfiguriert war, nicht mehr stattfinden kann. Nachdem das TLB-Abwerfen und die Migration des Datenpostens zurück in Speicherung abgeschlossen ist, wird die anfordernde Anwendung/Bibliothek über den Abschluss informiert und der aktive Bibliotheksdatensatz für den Datenposten und seine virtuelle Adresse werden gelöscht oder anderweitig deaktiviert.
Die Prozessorhardware 420 kann mit speziellen Merkmalen implementiert sein, um die oben beschriebene Umgebung und das oben beschriebene Modell zu unterstützen. Zum Beispiel kann der Prozessor modellspezifischen Registerplatz oder eine andere Form von Registerplatz und zugeordnete Logikschaltkreise umfassen, um Kommunikation zwischen dem Massenspeicherungstreiber 412 und dem Prozessor 420 zur Implementierung der oben beschriebenen Umgebung/des oben beschriebenen Modells zu ermöglichen. Zum Beispiel kann der Prozessor speziellen Registerplatz umfassen, in den das Massenspeicherungslaufwerk die der Anforderung 418 zugeordnete Prozess_ID und/oder virtuelle Adresse schreibt, um einen Datenposten in persistenten Systemspeicher 416 zu verlagern. Dem Registerplatz zugeordnete Logikschaltkreise können mit der MMU oder anderer Prozessorhardware gekoppelt sein, um dabei zu helfen, die Anforderungs-Antwort-Semantik bzw. Semantiken auszuüben.
Außerdem kann Registerplatz existieren, durch den die Prozessorhardware die neue virtuelle Adresse zur Verwendung mit dem Datenposten zurückgibt. Die MMU oder andere Prozessorhardware kann auch spezielle Hardware umfassen, um die neue virtuelle Adresse als Reaktion auf die Anforderung zu bestimmen. Der Speichercontroller kann spezielle Logikschaltkreise zum Lesen eines Datenpostens (z.B. einer Seite von Informationen) aus einer Region von Systemspeicher (z.B. einer Region von persistentem Speicher) und Rückschreiben dieses in die persistente Speicherregion, von wo aus auf den Datenposten im DAX-Emulationsmodus zuzugreifen ist, umfassen.
5 zeigt eine Abbildung eines beispielhaften Datenverarbeitungssystems 500, wie etwa eines persönlichen Datenverarbeitungssystems (z.B. Desktop oder Laptop) oder eines mobilen oder in der Hand gehaltenen Datenverarbeitungssystems, wie etwa einer Tablet-Vorrichtung oder eines Smartphones oder eines größeren Datenverarbeitungssystems, wie etwa eines Server-Datenverarbeitungssystems.
Wie in 5 zu sehen ist, kann das grundlegende Datenverarbeitungssystem Folgendes umfassen: eine Zentralverarbeitungseinheit 501 (die z.B. mehrere Vielzweck-Verarbeitungskerne und einen Hauptspeichercontroller, angeordnet auf einem Anwendungsprozessor oder Mehrkernprozessor, umfassen kann), Systemspeicher 502, eine Anzeige 503 (z.B. Touchscreen, Flachbildschirm), eine lokale verdrahtete Punk-zu-Punkt-Verbindungs-(z.B. USB-)Schnittstelle 504, verschiedene E/A-Funktionen 505 (wie etwa eine Ethernet-Schnittstelle und/oder ein Mobilfunkmodem-Subsystem), eine drahtlose Lokalnetzwerk-(z.B. WiFi-)Schnittstelle 506, eine drahtlose Punkt-zu-Punkt-Verbindungs-(z.B. Bluetooth-)Schnittstelle 507 und eine Global-Positioning-Schnittstelle 508, verschiedene Sensoren 509_1 bis 509_N (z.B. eines oder mehrere von einem Kreisel, einem Beschleunigungsmesser, einem Magnetometer, einem Temperatursensor, einem Drucksensor, einem Feuchtigkeitssensor usw.), eine Kamera 510, eine Batterie 511, eine Power-Management-Steuereinheit 512, einen Lautsprecher und ein Mikrofon 513 und einen Audiocodierer/-decodierer 514.
Ein Anwendungsprozessor oder Mehrkernprozessor 550 kann einen oder mehrere Vielzweck-Verarbeitungskerne 515 in seiner CPU 501, eine oder mehrere grafische Verarbeitungseinheiten 516, eine Speicherverwaltungsfunktion 517 (z.B. einen Speichercontroller) und eine E/A-Steuerfunktion 518 umfassen. Die Vielzweck-Verarbeitungskerne 515 führen typischerweise das Betriebssystem und Anwendungssoftware des Datenverarbeitungssystems aus. Die Grafikverarbeitungseinheiten 516 führen typischerweise grafikintensive Funktionen aus, um z.B. Grafikinformationen zu erzeugen, die auf der Anzeige 503 präsentiert werden. Die Speichersteuerfunktion 517, die als Hauptspeichercontroller oder Systemspeichercontroller bezeichnet werden kann, ist an den Systemspeicher 502 angeschaltet. Der Systemspeicher 502 kann ein Mehrebenen-Systemspeicher sein.
Das Datenverarbeitungssystem, einschließlich etwaiger Kernel-Ebenen- und/oder Anwendungssoftware, kann in der Lage sein, den DAX-Modus wie oben ausführlich beschrieben zu emulieren.
Die Touchscreen-Anzeige 503, die Kommunikationsschnittstellen 504-507, die GPS-Schnittstelle 508, die Sensoren 509, die Kamera 510 und der Lautsprecher-/Mikrofoncodec 513, 514 können jeweils alle als verschiedene Formen von E/A (Eingabe und/oder Ausgabe) relativ zum Gesamt-Datenverarbeitungssystem angesehen werden, das gegebenenfalls auch eine integrierte Peripherievorrichtung (z.B. die Kamera 510) umfasst. Abhängig von der Implementierung können verschiedene dieser E/A-Komponenten auf dem Anwendungsprozessor/Mehrkernprozessor 550 integriert sein oder können sich außerhalb des Chips oder außerhalb der Kapselung des Anwendungsprozessors/Mehrkernprozessors 550 befinden. Die nichtflüchtige Speicherung 520 kann das BIOS und/oder Firmware des Datenverarbeitungssystems halten.
Eine oder mehrere verschiedene Signalleitungen in dem Datenverarbeitungssystem, z.B. eine Daten- oder Adressenleitung eines Speicherbusses, der den Hauptspeichercontroller mit dem Systemspeicher koppelt, können einen Empfänger umfassen, der als eine Entscheidungsrückmeldungs-Entzerrerschaltung implementiert ist, die intern Änderungen der Elektronenmobilität wie oben beschrieben kompensiert.
Ausführungsformen der Erfindung können verschiedene Prozesse wie oben dargelegt umfassen. Die Prozesse können in maschinenausführbaren Anweisungen realisiert sein. Die Anweisungen können verwendet werden, um zu bewirken, dass ein Vielzweck- oder Spezialprozessor bestimmte Prozesse ausführt. Als Alternative können diese Prozesse durch spezifische Hardwarekomponenten ausgeführt werden, die festverdrahtete Logik zum Ausführen der Prozesse enthalten, oder durch eine beliebige Kombination von programmierten Computerkomponenten und angepassten Hardwarekomponenten.
Elemente der vorliegenden Erfindung können auch als maschinenlesbares Medium zum Speichern der maschinenausführbaren Anweisungen bereitgestellt werden. Das maschinenlesbare Medium kann, aber ohne Beschränkung darauf, Folgendes umfassen: Disketten, optische Datenträger, CD-ROM und magnetooptische Datenträger, Flash-Speicher, ROM, RAM, EPROM, EEPROM, magnetische oder optische Karten, Ausbreitungsmedien oder andere Arten von Medien/maschinenlesbarem Medium, das zum Speichern von elektronischen Anweisungen geeignet ist. Zum Beispiel kann die vorliegende Erfindung als Computerprogramm heruntergeladen werden, das mittels Datensignalen, die in einer Trägerwelle oder einem anderen Ausbreitungsmedium über eine Kommunikationsstrecke (z.B. ein Modem oder eine Netzwerkverbindung) realisiert sind, von einem entfernten Computer (z.B. einem Server) zu einem anfordernden Computer (z.B. einem Client) transferiert werden kann.

Claims

Prozessor, umfassend: Registerplatz zum Annehmen von Eingangsparametern eines Softwarebefehls zum Verlagern eines Datenpostens aus Computersystem-Speicherung heraus und in persistenten Systemspeicher, wobei die Eingangsparameter eine Kennung eines Softwareprozesses, der Zugriff auf den Datenposten in dem persistenten Systemspeicher wünscht, und eine virtuelle Adresse des Datenpostens, auf die sich der Softwareprozess bezieht, umfassen.
Prozessor nach Anspruch 1, wobei der Prozessor ferner Registerplatz zum Zurückgeben einer anderen virtuellen Adresse zur Verwendung beim Zugriff auf den Datenposten im persistenten Systemspeicher als Reaktion auf den Befehl umfasst.
Prozessor nach Anspruch 2, wobei Speicherverwaltungseinheits- bzw. MMU-Logikschaltkreise des Prozessors die neue virtuelle Adresse als Reaktion auf die Anforderung bestimmen sollen.
Prozessor nach Anspruch 3, wobei die MMU-Logikschaltkreise einen neuen Eintrag in einen TLB (Translation Look-Aside Buffer) des Prozessors eingeben sollen, um die neue virtuelle Adresse in eine Adresse des persistenten Systemspeichers zu übersetzen, die für den Zugriff auf den Datenposten im persistenten Systemspeicher benutzbar ist.
Prozessor nach Anspruch 1, wobei der Prozessor den Datenposten aus einer Massenspeicherungs-Cache-Region des Systemspeichers in den persistenten Systemspeicher verlagern soll, wenn der Datenposten in der Massenspeicherungs-Cache-Region residiert.
Prozessor nach Anspruch 1, wobei, wenn der Datenposten in einer Massenspeicherungs-Cache-Region des Systemspeichers residiert, die Adresse, an der der Datenposten residiert, als persistentem Systemspeicher, statt dem Massenspeicherungs-Cache, zugeordnet umcharakterisiert wird.
Prozessor nach Anspruch 1, wobei ein Massenspeicherungs-Kernel den Softwarebefehl im Namen des Softwareprozesses ausgibt.
Datenverarbeitungssystem, das den Prozessor nach einem der Ansprüche 1 bis 7 umfasst.
Maschinenlesbares Speicherungsmedium, das Programmcode enthält, der, wenn er durch einen Prozessor eines Datenverarbeitungssystems verarbeitet wird, bewirkt, dass das Datenverarbeitungssystem ein Verfahren ausführt, wobei das Datenverarbeitungssystem persistenten Systemspeicher umfasst und das Verfahren Folgendes umfasst: Empfangen einer Anforderung durch eine Anwendung, einen Datenposten aus Speicherung zu entfernen und den Datenposten im persistenten Systemspeicher zu platziergen; Leiten einer Kennung eines Softwareprozesses, der die Anwendung ausführt, und einer virtuellen Adresse, die die Anwendung zur Bezugnahme auf den Datenposten verwendet, zu dem Prozessor; Empfangen einer neuen virtuellen Adressen für den Datenposten, die durch die Anwendung beim Zugreifen auf den Datenposten im persistenten Systemspeicher zu verwenden ist, von dem Prozessor; und Weiterleiten der neuen virtuellen Adresse zu der Anwendung als Reaktion auf die Anforderung.
Maschinenlesbares Speicherungsmedium nach Anspruch 9, wobei der Programmcode Programmcode auf Kernel-Ebene ist.
Maschinenlesbares Speicherungsmedium nach Anspruch 10, wobei der Programmcode auf Kernel-Ebene ein Massenspeicherungs-Kernel ist.
Maschinenlesbares Medium nach Anspruch 9, wobei die Anwendung eine Speicherungsanwendung ist.
Maschinenlesbares Medium nach Anspruch 9, wobei die Anwendung eine Bibliotheksanwendung ist, die als Repositorium zum Abwickeln von Zugriffen auf Datenposten im persistenten Speicher in einem DAX-Emulationsmodus wirkt.
Maschinenlesbares Medium nach Anspruch 13, wobei es mehreren Anwendungen gestattet ist, auf die Bibliotheksanwendung zuzugreifen.
Vorrichtung, umfassend: Mittel zum Empfangen einer Anforderung durch eine Anwendung, einen Datenposten aus Speicherung zu entfernen und den Datenposten im persistenten Systemspeicher zu platzieren; Mittel zum Leiten einer Kennung eines Softwareprozesses, der die Anwendung ausführt, und einer virtuellen Adresse, die die Anwendung zur Bezugnahme auf den Datenposten verwendet, zu dem Prozessor; Mittel zum Empfangen einer neuen virtuellen Adressen für den Datenposten, die durch die Anwendung beim Zugreifen des Datenpostens im persistenten Systemspeicher zu verwenden ist, von dem Prozessor; und Mittel zum Weiterleiten der neuen virtuellen Adresse zu der Anwendung als Reaktion auf die Anforderung.