-
Technisches Gebiet
-
Das Gebiet der Erfindung betrifft allgemein die Datenverarbeitungswissenschaft und insbesondere ein Solid-State-Drive mit externer Softwareausführung zur Bewirkung interner Operationen des Solid-State-Drive.
-
Hintergrund
-
Mit dem Aufkommen von Cloud-Datenverarbeitung, „Big Data“, künstlicher Intelligenz und anderen rechnerisch intensiven Umgebungen zeigt sich Massenspeicherung als kritische Komponente der Gesamt-Datenverarbeitungssystemleistungsfähigkeit. Dementsprechend suchen Datenverarbeitungssystementwickler fortwährend nach Möglichkeiten, bei Massenspeicherungsvorrichtungen die Latenzen zu verringern, den Durchsatz zu vergrößern, die Leistung zu optimieren und/oder Robustheit zu gewährleisten.
-
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 ein traditionelles Datenverarbeitungssystem mit Solid-State-Drives;
- 2 ein verbessertes Datenverarbeitungssystem mit Solid-State-Drives;
- 3 eine Datenstruktur, die von Programmcode von Solid-State-Drives verwendet wird, der aus einem Systemspeicher heraus ausgeführt wird;
- 4 ein Datenverarbeitungssystem.
-
Ausführliche Beschreibung
-
1 zeigt ein traditionelles Mehrprozessor-Computersystem 100. Wie in 1 zu sehen ist, umfasst das Computersystem mehrere Vielzweck-, anwendungsspezifische und/oder umkonfigurierbare Verarbeitungskerne 101_1 bis 101_N. Jeder der Verarbeitungskerne umfasst typischerweise mehrere Anweisungsausführungs-Pipelines, wobei jede dieser Pipelines über ihren eigenen dedizierten LI-Cache (zur besseren Veranschaulichung in 1 nicht gezeigt) oder Scratchpad-Speicher verfügt. Jeder Verarbeitungskern umfasst außerdem einen L2-Cache 102_1 bis 102_N, der seine Anweisungsausführungs-Pipelines bedient. Die Verarbeitungskerne 101 werden durch ein Netzwerk 103 miteinander, mit einem L3-Cache 104 (der die Verarbeitungskerne bedient), mit einem Systemspeicher-Controller 105 und einem Peripherie-Steuerhub 106 verbunden.
-
Wie in der Technik bekannt ist, führt, wenn ein Thread von Programmcode, der gerade mittels einer der Pipelines ausgeführt wird, Daten benötigt, die sich nicht im Registerraum der Pipeline befinden, der Programmcode eine Speicherzugriffsanforderung aus, die die Speicheradresse der benötigten Daten spezifiziert. Statt die Daten sofort aus dem Systemspeicher 107 (der auch als „Hauptspeicher“ bezeichnet wird) abzurufen, sucht das System stattdessen in dem LI-Cache der Pipeline nach dem Datenposten. Wenn sich der Posten nicht in dem LI-Cache befindet, betrachtet das System als Nächstes den L2-Cache des Kerns, auf dem die Pipeline instanziiert ist. Wenn sich der Posten nicht im L2-Cache befindet, sucht das System in dem L3-Cache 104 nach dem Datenposten. Wenn sich der Posten nicht im L3-Cache 104 befindet, ruft es den Posten dann über den System-Speichercontroller 105 (auch als Hauptspeichercontroller 105 bezeichnet) aus dem Systemspeicher 107 ab.
-
Der L1- und L2-Cache der verschiedenen Kerne, sowie der L3-Cache 104, sind alle Cache-kohärent. Cache-Kohärenz wird mit einem Protokoll implementiert, wie etwa dem MESI-Protokoll (Modified Exlusive Shared Invalid), das an jedem Zwischenspeicherungsort ausgeführt wird, um sicherzustellen, dass das System nicht in zwei verschiedene Versionen eines Datenpostens schreibt. Da mehrere ausgeführte Software-Threads auf einer oder mehren der Pipelines und/oder einem oder mehreren der Kerne gleichzeitig dieselben Daten mit der Absicht, sie mit neuen Informationen zu aktualisieren, wünschen können, verhindert das Cache-Kohärenzprotokoll hier effektiv, dass durch zwei verschiedene Software-Threads mit verschiedenen Daten in zwei verschiedene Instanzen der Daten geschrieben wird.
-
Wie in 1 zu sehen ist, hat jeder der Threads, die auf den verschiedenen Kernen ausgeführt werden, seinen eigenen dedizierten Betriebsraum oder „Footprint“ 108_1 bis 108_M im Systemspeicher 107. Ein solcher Footprint existiert gewöhnlich für jede Softwareanwendung, die das System gerade ausführt. Jeder Footprint 108 umfasst typischerweise Programmcodeanweisungen und Daten seines entsprechenden Threads.Der Footprint eines Threads enthält jedoch in der Regel nicht den gesamten Programmcode, der ausgeführt werden könnte, oder alle Daten, an denen durch den Thread operiert werden kann. Dementsprechend werden Seiten von Programmcode und/oder Speicher aus der Massenspeicherung 109 aufgerufen und je nach Bedarf in den Footprint eines Threads geschrieben (gewöhnlich mit Ausschluss anderer Seiten in dem Footprint des Threads, die in Massenspeicherung zurückgeschrieben werden, um Platz für die neuen Seiten zu schaffen).
-
Mit dem Aufkommen von Cloud-Datenverarbeitung, „Big Data“, künstlicher Intelligenz und anderen rechnerisch intensiven Umgebungen zeigt sich Massenspeicherung 109 als kritische Komponente der Gesamt-Datenverarbeitungssystemleistungsfähigkeit. Hier benötigen viele Softwareanwendungen Zugriff auf Mengen an Daten, die die Zuteilung des Footprints 108 der Anwendung im Hauptspeicher 107 weit übersteigen. Dementsprechend gibt es in der Regel häufige Aufrufe nach Seiten aus Massenspeicherung 109 (wie in 1 zu sehen ist, wird Massenspeicherung mit mehreren Massenspeicherungsvorrichtungen 110_1 bis 110_X implementiert, die mit einem PCH (Peripheral Control Hub) 106 gekoppelt sind). Je schneller solche Seiten aus der Massenspeicherung 109 abgerufen werden können, desto geringer ist das Risiko, dass eine Anwendung beim Warten, bis Seiten von Daten aus der Massenspeicherung 109 abgerufen und in den Systemspeicher 107 eingetragen werden, stecken bleibt.
-
Außerdem nehmen wieder zur Erfüllung des insgesamten erhöhten Bedarfs an großen Mengen von Daten die Speicherungskapazitäten der Massenspeicherungsvorrichtungen selbst 110_1 bis 110 X (z.B. von SSD Solid-State-Drives)) mit jeder neuen Produktgeneration stetig zu.
-
Ein Problem mit der erhöhten SSD-Kapazität ist jedoch die vergrößerte Funktionalität, die jedes SSD erwartungsgemäß unterstützen soll. Jedes SSD umfasst hier gewöhnlich einen Controller und zugeordneten Speicher zur Ausführung von Logik 111_1 bis 111_X, die den Betrieb des SSD beaufsichtigt. Eine solche Beaufsichtigung umfasst gewöhnlich Folgendes: 1) Abnutzungsnivellierung; 2) Müllabfuhr; und 3) Übersetzung von LBA (logischer Blockadresse) in PBA (physische Blockadresse).
-
Die physischen Speicherungsmedienblöcke/-zellen eines SSD (z.B. NAND-Flash, dreidimensionaler Kreuzpunkt-NVRAM (nichtflüchtiger Direktzugriffsspeicher), wie etwa der Speicher Optane™ von der Intel Corporation, der Speicher QuantX™ von Micron usw.) können sich jedoch verschlechtern/abnutzen, wenn zu häufig in sie geschrieben wird. Dementsprechend verfolgt bei der Durchführung von Abnutzungsnivellierung die SSD-Controllerlogik 111, in welche ihrer Blöcke am häufigsten geschrieben wurde, und unterbricht, wenn eine gewisse Schwelle überschritten wird, SSD-Operationen, um die „heißen“ Daten aus ihrem aktuellen Block bzw. ihren aktuellen Blöcken zu lesen und selbige in andere Blöcke zu schreiben, in die weniger häufig geschrieben wurde.
-
Um heiße Daten in einen anderen Block zu schreiben, muss der andere Block zuerst „gesäubert“ werden. Um Abnutzungsnivellierung zu unterstützen, muss somit die SSD-Controllerlogik 111 auch Müllabfuhr durchführen. Müllabfuhr ist der Vorgang des Identifizierens von Blöcken, deren Daten abgestanden sind (z.B. deren Daten wurden zu einem anderen Block verlagert) oder auf die kaum zugegriffen wurde, und des Vorbereitens dieser für Überschreibung mit neuen Daten. Im Fall eines identifizierten abgestandenen Blocks wird der Block gelöscht und in eine Frei-Liste von wahlfähigen Blöcken, in die frisch geschrieben werden soll, eingetragen. Im Fall eines Blocks, dessen Daten nicht abgestanden sind, aber auf die kaum zugegriffen wird, werden die Daten des Blocks gelesen und in einen anderen Block geschrieben. Der Block wird dann gelöscht und in die Frei-Liste eingetragen.
-
Da die SSD-Controllerlogik 111 die physischen Blöcke, in denen spezifische Daten gespeichert sind, auswechselt oder ändert, führt die SSD-Controllerlogik 111 auch Adressenübersetzung von LBA in PBA durch. Wenn das größere Host-Computersystem wünscht, auf eine spezifische Seite oder spezifische Seiten von Daten zuzugreifen, identifiziert es hier die Daten mit einer LBA. Der SSD-Controller setzt die LBA dann in den physischen Block bzw. die physischen Blöcke im SSD um, in denen die Daten tatsächlich residieren. Jedes Mal, wenn eine Abnutzungsnivellierungsoperation Verlagerung von Daten in einen anderen Block (Blöcke) bewirkt, muss hier eine Tabelle von LBA in PBA aktualisiert werden, um den neuen physischen Ort der Daten im SSD widerzuspiegeln.
-
Mit der sich immer mehr erweiternden Speicherungskapazität von SSD werden leider Abnutzungsnivellierung, Müllabfuhr und Übersetzung von LBA in PBA für sie rechnerisch intensiver, was sich wiederum vom Standpunkt des Hosts aus gesehen auf SSD-Latenzen auswirkt. Das heißt, mit jeder neuen SSD-Generation wird es schwieriger, ein „schnelleres“ SSD herzustellen. Stattdessen besteht bei den SSD das Risiko, dass sie verglichen mit ihren früheren Generationen im Mittel längere Lese-/Schreiblatenzen aufweisen.
-
Weiterhin vergrößert das Integrieren von rechnerisch intensiven Funktionen in das SSD zur Ausführung durch den SSD-Controller den SSD-Stromverbrauch. Mit sich vergrößernder SSD-Speicherungskapazität werden somit SSD langsamer und stromhungriger.
-
Eine SSD-Vorrichtungs-Softwareinstanz wird typischerweise für jedes SSD, das in das System integriert wird, in ein Betriebssystem oder eine Betriebssysteminstanz „eingesteckt“. Treibersoftware einer SSD-Vorrichtung wird gewöhnlich verwendet, um mittels Software das SSD zu konfigurieren oder anderweitig darauf zuzugreifen. Der Vorrichtungstreiber nimmt gewöhnlich Befehle von einer höheren Schicht von Software, wie etwa dem Betriebssystem oder der Anwendung, an und erzeugt aus diesen Befehlen Befehle für den SSD-Controller. Mittels Ausführung von lokaler Firmware des SSD verarbeitet der SSD-Controller die Befehle daraufhin. Hier gibt es mehrere distinkte Schichten von SSD-Programmcode, die gleichzeitig ausgeführt werden: 1) die Vorrichtungstreibersoftware, die auf einem Verarbeitungskern 101 als Software ausgeführt wird; 2) Firmware, die die Logik 111 im SSD selbst ausführt; und 3) Komponenten-Mikrocode, der an der Komponente operiert. Dass mehrere distinkte Schichten eines komplexen Programms gleichzeitig für ein SSD ausgeführt werden, trägt auch zur insgesamten SSD-Latenz bei.
-
Eine Lösung für beliebige/alle dieser Probleme ist in 2 abgebildet. Wie in 2 zu sehen ist, wird die lokale Logikfunktionalität 211 des SSD, die traditionell durch den Controller des SSD ausgeführt wurde, stattdessen ganz oder teilweise als ein Thread implementiert, der auf einem Vielzweck-CPU-Kern ausgeführt wird (wie in 2 zu sehen ist, sind mehrere SSD 210_1 bis 210_X mit einem PCH (Peripheral Control Hub) 206 gekoppelt). Das heißt, soweit SSD-Controller traditionell „Firmware“ ausgeführt haben, die in dem SSD (mit einem Controller/Prozessor und Speicher integriert im SSD) lokal gespeichert und ausgeführt wurde, um die Logik 111 zu implementieren, wird der Firmware-Programmcode (oder zumindest Programmcode zum Bewirken der Logik 111 traditioneller SSD-Firmware) bei dem Ansatz von 2 stattdessen als ein Footprint 211 im Systemspeicher 207 instanziiert. Die Controlleroperationen auf niedriger Ebene für das SSD, die traditionell als lokale Firmware im SSD ausgeführt wurden, werden dann stattdessen mit einem Thread des Vielzweck-Verarbeitungskerns 201 aus dem Systemspeicher-Footprint ausgeführt, z.B. nicht anders als ein nominales Anwendungssoftwareprogramm.
-
Da die rechnerisch intensiven SSD-Controlleroperationen auf niedriger Ebene zum großen Teil aus den SSD 210 herausgeholt und stattdessen mehr wie nominale Anwendungssoftwareprogramme implementiert werden, sollten die SSD 210 eine unmittelbare Beschleunigung, ein erhöhtes Betriebsleistungspotential der Vorrichtung und Reduktion des Energie-Footprint aufweisen. Während zum Beispiel traditionelle SSD-Operationen des Lesens oder Schreibens (hier als „Programmieren“ bezeichnet) wegen durch den SSD-Controller durchgeführter Abnutzungsnivellierung oder Müllabfuhr stecken blieben oder sich aufgrund der durch den SSD-Controller durchgeführten Übersetzung von LBA in PBA verlangsamten, verfolgen bei dem Ansatz von 2 die SSD 210 selbst bei verschiedenen Ausführungsformen nicht heiße Blöcke im Vergleich zu kalten, bestimmen nicht, welche Blöcke eine relative Heiß-Schwelle für Abnutzungsnivellierung überschritten haben, identifizieren keine Blöcke für Müllabfuhr und führen auch keine Übersetzungen von LBA in PBA oder irgendwelche anderen damit zusammenhängenden Operationen aus (wie etwa Identifizierung von Fehlerblöcken, Zurückziehen von Fehlerblöcken, Durchführen von Medienbreiten-Schreibmodus-Kontextwechseln (SLC (Einzelpegelzelle), MLC (Mehrpegelzelle), TLC (Dreipegelzelle), QLC (Quad-Pegelzelle) usw.), Revektorisierung von Blöcken für neue Übersetzungen, Umordnungsoperationen usw.). Stattdessen werden alle solche Funktionen durch einen Vielzweck-Verarbeitungskern aus Hauptspeicher heraus ausgeführt.
-
Da solche rechnerisch intensiven Operationen aus den SSD 210 herausgeholt werden, sollten die SSD 210 außerdem weniger Strom pro Einheit gespeicherter Daten verbrauchen. Während der vorbekannte Ansatz von 1 zwei distinkte Schichten von komplexem und gleichzeitig integriertem Programmcode zur Verwendung und Implementierung eines Gesamt-SSD benutzt hat, kann im Gegensatz dazu weiterhin bei dem Ansatz von 2 Vorrichtungstreiber- und traditionelle Firmwarelogik für jedes SSD als eine einzige „engere“ Schicht von Software, die die Funktionalität des traditionellen SSD-Vorrichtungstreibers und der Firmware subsummiert, zu einer einzigen Instanz von Programmcode 211 synthetisiert werden.
-
Darüber hinaus hatte traditionell nur ein SSD-Controller Zugang zu tieferen Kontextdetails eines SSD, in die Programmcode auf höherer Ebene, wie etwa der Vorrichtungstreiber des SSD, nicht eingeweiht war. Speziell enthalten traditionelle SSD typischerweise internen Registerraum (z.B. eingebettet auf den Speicherchips des SSD, dem Controllerchip des SSD oder beliebiger anderer interner SSD-Hardware, wie etwa ein FPGA (Field Programmable Array) (z.B. verwendet zur Beschleunigung verschiedener Prozesse)), die außerhalb des SSD nicht sichtbar sind und auf die nur der SSD-Controller zugreift, um spezifische Merkmale des SSD zu programmieren.
-
Die Menge von konfigurierbarem Registerraum, die als Register- oder Konfigurations-„Kontext“ des SSD bezeichnet wird, wird traditionell verwendet, um bestimmte Modi und/oder Funktionen herzustellen, die vom SSD-Controller ausgeführt werden, die sich von Müllabfuhr, Abnutzungsnivellierung und LBA-PBA-Übersetzung unterscheiden, wie etwa Bandbreitenarbitrierung (wobei das SSD um eine bestimmte Kommunikationsgeschwindigkeit zwischen dem SSD und dem Host mit dem Host verhandelt); Medienblockverpackung (Programmierung der Speicherzellendichte eines oder mehrerer Speicherblöcke (z.B. als eines von SLC, MLC, TLC, QLC); Redundanz (Speichern mehrerer Instanzen eines einzelnen Datenpostens); Detektion von Fehlern; Korrektur von Fehlern; Datenauffrischung (Neuprogrammierung derselben Daten in eine Zelle, die für einen längeren Zeitraum in der Zelle resident waren); Verschlüsselung von Daten (zum Sicherheitsschutz); Konfiguration eines internen Hardware-Beschleunigers im SSD (wie etwa eine FPGA (Field Programmable Gate Array), das dafür ausgelegt ist, interne Leistungsfähigkeitsverfolgung und Statistiken durchzuführen); Konfigurieren von Tiefe und/oder Bedienungsrate von Warteschlange(n) im SSD (z.B. zum Bedienen einer bestimmten Host-SSD-Schnittstellengeschwindigkeit); Snooping einer Befehlswarteschlange (was auch im Hauptspeicher implementiert wird), um mehrere identische Befehle zu einem einzigen Befehl zu konsolidieren; usw. Beim vorliegenden Ansatz können beliebige/alle dieser Funktionen ganz oder teilweise außerhalb des SSD ausgeführt werden, z.B. als Programmcode, der aus Systemspeicher heraus ausgeführt wird. Wieder würden Befehle aus dem ausgeführten Programmcode auf dem Computerhost mittels der Hardware des Hosts (z.B. über ein Peripheral Control Hub) an das SSD gerichtet, um z.B. in Register im SSD zu schreiben und/oder aus diesen zu lesen, um zu bewirken, dass beliebige/alle dieser Funktionen ausgeführt werden und um beliebige spezifische Parameter, gemäß denen sie operieren sollen, bereitzustellen und/oder zu melden.
-
Dementsprechend umfasst Register- oder Konfigurationskontext in einem SSD (der den internen Kontext des SSD beschreibt), der traditionell nur dem SSD-Controller zugänglich war, aber bei dem neuen Ansatz Programmcode, der aus Systemspeicher heraus ausgeführt wird, programmierbar und/oder sichtbar gemacht werden kann, neben anderen möglichen Kontextinformationen Registerraum mindestens für Folgendes: 1) individuelles Ein- oder Ausschalten von nichtflüchtigen Speicherchips und/oder individuelles Freigeben dieser; 2) Aufzeichnen von Informationen, die angeben, ob Fehlerdetektion freigegeben ist, und wenn dem so ist, welche Art von Fehlerdetektion benutzt wird (z.B. Parität, zyklische Redundanzprüfung usw.); 3) Aufzeichnen von Informationen, die angeben, ob ECC (Fehlerkorrekturcodierung) freizugeben oder zu sperren ist (z.B. für einzelne Speicherchips oder Gruppen von Speicherchips), und wenn dem so ist, welcher spezifische ECC-Algorithmus auszuführen ist; 4) Aufzeichnen von Informationen, die angeben, ob von einem Speicherchip oder Teil davon Daten verschlüsselt werden, und wenn dem so ist, welche Art von Verschlüsselung anzuwenden ist; 5) Informationen, die spezifizieren, welches Protokoll an der Schnittstelle von SSD/Host zu implementieren ist (z.B. PCIe (Peripheral Component Interconnect Express), NVMe (Non-Volatile Memory Express, SATA (Serial AT Attachment) usw.); 6) Informationen, die angeben, ob Daten zu replizieren sind oder nicht (z.B. wird eine zweite Version von in einem Block gespeicherten Daten zusätzlich in einem anderen Block gespeichert, um vor Verlust der Daten zu schützen) und/oder etwaigen anderen Registerraum zum Helfen bei der Implementierung beliebiger/aller der im vorhergehenden Absatz benannten Funktionen usw.
-
Mit der Möglichkeit, einen solchen SSD-Kontext von einer ausgeführten Anwendung aus zu konfigurieren, wie bei dem Ansatz von 2, können bestimmte feinabgestimmte, präzise Betriebseffizienzen realisiert werden, die bisher nicht möglich waren. Ein Beispiel ist sehr präzises kontrolliertes SSD-Herauffahren während des Einschaltens und/oder Rücksetzens. Zum Beispiel war es traditionell, wenn ein SSD eingeschaltet oder rückgesetzt wurde, schwierig, seinen Stromverbrauch allmählich in einer Reihe von eng kontrollierten sequenziellen Schritten heraufzufahren. Das heißt, das SSD war mehr oder weniger voll „eingeschaltet“, darunter z.B. alle Speicherchips und/oder andere Hardware im SSD. Dementsprechend wies der Stromverbrauch des SSD eine Sprungfunktionsantwort auf. Das heißt, das SSD war entweder „ausgeschaltet“, wobei in diesem Fall sein Stromverbrauch gering war, oder das SSD war „eingeschaltet“, wobei in diesem Fall sein Stromverbrauch hoch war (z.B. weil alle Speicherchips im SSD eingeschaltet waren).
-
Im Gegensatz dazu kann mit dem Exponieren von SSD-Kontext für Footprint/Anwendung des SSD wie bei dem Ansatz von 2 der Stromverbrauch eines SSD sehr präzise mit Software kontrolliert werden, wie etwa Einschalten spezifischer Speicherchips und/oder Beschleuniger gemäß einer sehr spezifischen Herauffahrsequenz. Das heißt, mit der Zeit kann der Stromverbrauch des SSD mehr wie eine Treppenfunktion statt wie eine Sprungfunktion hochgefahren werden. Statt zum Beispiel alle Speicherchips des SSD einzuschalten, sobald das SSD eingeschaltet ist, werden stattdessen einzelne Speicherchips nur nach Bedarf eingeschaltet, während das SSD beginnt, sich mit Daten aufzufüllen.
-
Bei einer Ausführungsform kann der Footprint/Anwendungscode 211 für ein SSD im Systemspeicher 207 ein sicheres Festwertspeicher-Einführen zum SSD-Booten erfordern. Bei einer Ausführungsform bewirkt der Bootprozess für ein SSD, der aus dem Footprint/der Anwendung 211 des SSD im Systemspeicher 207 heraus ausgeführt wird, dass das SSD die folgende Herauffahrsequenz ausführt: 1) Freigeben der Hostschnittstelle (z.B. PCIe) des SSD; 2) Warten darauf, dass der Host (z.B. ein Mehrprozessor-CPU-SOC-Halbleiterchip (System-on-Chip)) mittels der Hostschnittstelle des SSD die Präsenz des SSD anerkennt; 3) Vorbereiten der Speicherchips des SSD für das Einschalten; und 4) Freigeben etwaiger Onboard-SSD-Beschleuniger je nach Wunsch (z.B. CRC/ECC-Beschleuniger (zyklische Redundanzprüfung/Fehlerkorrekturcodierung), Verschlüsselungs-/Entschlüsselungsbeschleuniger, Medienkanal-Warteschlangenbeschleuniger, Leistungsfähigkeits-Trace-Analysebeschleuniger, numerische Rechenbeschleuniger). Beliebiger/aller anderer SSD-Konfigurationskontext kann schnell je nach Bedarf aus Systemspeicher durch Ausführen des SSD-Footprint an dem SSD umgewechselt werden.
-
Bei verschiedenen Ausführungsformen wird die Sequenz mittels einer Sequenz von durch den ausgeführten SSD-Footprint-/-Anwendungscode erzeugten Befehlen, die von dem CPU-SOC-aus an das SSD ausgegeben werden, und vom SSD zu dem CPU-SOC und ausgeführtem SSD-Footprint-Code zurückgesendeter Statusnachrichtenantworten bewirkt. Beim Ausgeben eines Befehls an das SSD kann der Footprint/Anwendungscode des SSD in reservierten Registerraum in dem Host-CPU-Prozessor und/oder MMIO (speicherabgebildete E/A) im Systemspeicher schreiben. Die Hardware transportiert dann die Befehle physisch mittels der Host/SSD-Schnittstelle zum SSD. Ähnlich kann das SSD mittels der Host/SSD-Schnittstelle Antwortnachrichten in den CPU-SOC-Registerraum oder MMIO-Raum schreiben. Dementsprechend soll das Solid-State-Drive eine Anforderung von Informationen von einem Hostsystem, mit dem das Solid-State-Drive gekoppelt ist, empfangen, wobei die Informationen den internen Kontext des Solid-State-Drive beschreiben. Das Solid-State-Drive ruft daraufhin intern die Informationen ab und sendet dann die Informationen zum Hostsystem zur Unterstützung der Ausführung der verschiedenen SSD-Aufgaben, die es ausführt, durch das Hostsystem.
-
3 zeigt eine Ausführungsform einer Datenstruktur 300, die von dem Footprint/der Anwendung eines SSD verwendet wird, um Übersetzungen von LBA in PBA für das SSD durchzuführen. Die Datenstruktur 300 umfasst hier sowohl einen physischen Blockkontext 301 als auch einen virtuellen Blockkontext 302. Der physische Blockkontext 301 enthält Metadaten für jeden Block in jedem Speicherchip im SSD (z.B. in Tabellenform). Für jeden solchen physischen Block beschreiben die Metadaten, ob der Block gesund, vorläufig defekt, defekt oder offline ist. Bei weiteren Ausführungsformen können die Metadaten Zugriffe auf jeden physischen Block und/oder ob einige Blockdaten (z.B. welche Seiten) aller Daten eines Blocks ungültig oder gelöscht sind (z.B. für Müllabfuhr und/oder Abnutzungsnivellierungszwecke) verfolgen. Der physische Blockkontext kann auch ein Log umfassen, das neuere an den physischen Blöcken vorgenommene Änderungen vorübergehend aufzeichnet.
-
Der virtuelle Blockkontext 302 enthält effektiv die Abbildung von LBA auf PBA. Da der Footprint/die Anwendung auch Müllabfuhr- und Abnutzungsnivellierungslogik enthält, bestimmt der Footprint/die Anwendung, wann ein Block als „heiß“ betrachtet wird (auf der Basis der Metadaten in dem physischen Blockkontext 301) und seine Daten zu einem anderen Block verlagert bekommen sollte, in welchen freien Block die Daten zu verlagern sind, sowie Müllabfuhr- und Löschungsablaufplanung zur Aufrechterhaltung eines Pools freier Blöcke. Während der Footprint/die Anwendung dem SSD befiehlt, physische Daten von einem Block zu einem anderen Block zu verlagern, werden die virtuellen Kontextänderungen 302 mit einer neuen PBA für die konkrete LBA, der die verlagerten Daten entsprechen, aktualisiert.
-
Da die Abbildung von LBA auf PBA im Host durch Ausführen des SSD-Footprint/der SSD-Anwendung von Systemspeicher aus durchgeführt wird, ist zu beachten, dass jeder Lese-/Schreib-Löschbefehl, der durch den Footprint/die Anwendung an das SSD ausgegeben wird, eine PBA spezifiziert und nicht eine LBA. Das heißt, es wird eine PBA statt einer LBA von der Host-Hardware (dem CPU-SOC) zu dem tatsächlichen SSD geleitet. Alle Hostanwendungen, die das SSD als Massenspeicherung verwenden, rufen über eine API mit der LBA für den betroffenen Block bzw. die betroffenen Blöcke, die mittels der API spezifiziert werden, den Footprint/die Anwendung des SSD im Systemspeicher auf. Der SSD-Footprint/die SSD-Anwendung führt dann die Abbildung von LBA auf PBA durch und gibt den entsprechenden Befehl (z.B. Lesen/Programmieren) mit der PBA an das SSD aus.
-
Durch Exponieren von komplizierten Details wie dem Registerkontext, dem physischen Blockzustand und der Abbildung von LBA auf PBA jedes SSD in einem Datenverarbeitungssystem für Software auf höherer Ebene kann solche Software ihre SSD-Ressourcen besser lastausgleichen, um letztendlich bessere SSD-Latenzen als traditionelle Systeme zu bewirken. Speziell hatten in traditionellen Datenverarbeitungssystemen nur SSD-Controller Sicht in die Anforderungswarteschlangen ihrer jeweiligen SSD. Hier hat jede SSD-Vorrichtung typischerweise Warteschlangenplatz zum Einreihen von Befehlen, die vom Host empfangen werden, in Warteschlangen. Wenn der Host eine große Anzahl von Anforderungen in einer kurzen Zeit in ein SSD einspeist, ist die Warteschlange des SSD in der Lage, eine signifikante Anzahl der Anforderungen in Warteschlangen einzureihen, was wiederum zu verringertem SSD-Ansprechen führt (das SSD bedient z.B. nicht die meisten/alle der in Warteschlangen eingereihten Anforderungen bis alle vorhergehenden Anforderungen in der Warteschlange bedient worden sind).
-
Im Gegensatz dazu kann mit dem verbesserten Ansatz von 2 der Zustand des Footprint/Anwendungscodes eines SSD im Systemspeicher über die Kenntnis des internen Befehlswarteschlangenzustands seines SSD verfügen. Mit Kenntnis des Warteschlangenzustands in jedem SSD im System kann Software (wie etwa Datenbanksoftware oder Betriebssystemsoftware) die SSD im System besser lastausgleichen und das Senden von Speicherungsanforderungen zu SSD mit weniger vollen internen Warteschlangen über SSD mit volleren internen Warteschlangen favorisieren. Im Idealfall wird die Warteschlangenverzögerung über die SSD als Ganzes hinweg kleiner als in einem traditionellen System sein, bei dem keine solche Einsicht in den SSD-Warteschlangenzustand und entsprechender Lastausgleich existiert.
-
Hier beaufsichtigt und kontrolliert im Allgemeinen das kontrollierende Betriebssystem oder die kontrollierende Betriebssysteminstanz, wie viele Seiten einer Anwendung sich im Systemspeicher befinden und welche der Seiten der Anwendung sich im Systemspeicher befinden. Das heißt, das Betriebssystem oder die Betriebssysteminstanz weiß, wann eine Anwendung Seiten aus Massenspeicherung in Systemspeicher heraufbringen muss, und bestimmt, welche der Seiten der Anwendung aus Systemspeicher auszuräumen sind, um Platz für die ankommenden Seiten zu schaffen, die aus Massenspeicherung heraufgerufen werden.
-
Der verbesserte Ansatz von 2 erlaubt eine feiner abgestimmte Kontrolle von Seitenverlagerung zwischen Systemspeicher und Massenspeicherung, z.B. durch Konditionierung solcher Seitenverlagerung bezüglich der internen Warteschlangenzustände der SSD, die durch die Seitenverlagerung betroffen sein werden. Das heißt, Software auf höherer Ebene wird seitenverlagerungsbezogene Befehle (z.B. Lesevorgänge aus Massenspeicherung neuer Seiten zum Eintrag in Systemspeicher und Schreibvorgänge von aus Systemspeicher ausgeräumten Seiten in Massenspeicherung) auf SSD schieben, bei denen die Software sehen kann, dass es einen niedrigeren internen Befehlswarteschlangenzustand hat, statt solche Befehl auf SSD zu schieben, bei denen die Software sehen kann, dass es einen höheren internen Befehlswarteschlangenzustand aufweist. Soweit solche Software dafür ausgelegt ist, solche Seitenverlagerungen im Voraus vorzunehmen (d.h. Seiten werden aus Massenspeicherung aufgerufen, bevor sie tatsächlich benötigt werden), sollte das Gesamtsystem reduzierte SSD-Latenzen ohne jegliche Anwendungssoftware-Hänger sehen.
-
Ferner können SSD in Pools geteamt werden, um Operationen direkt zwischen Datenverlagerung, Auswechselung und/oder Replikation abzuladen. Diese geteamten Kennungen können dann dergestalt verwendet werden, dass jede Kennungsgruppe Operationen wie etwa Schreibvorgänge zum Duplizieren interner Schreibfehle mit Reduktion von Befehlen von vielen auf einen snoopen wird, wodurch das Hostsystem-Busbandbreitenpotential vergrößert wird.
-
Des Weiteren kann, sobald eine Instanz von traditionellem SSD-Firmware-Programmcode in Systemspeicher instanziiert ist, ihr Zweck für irgendeine andere Hardwarekomponente umfunktioniert werden. Zum Beispiel kann Programmcode zur Implementierung eines etwaigen Verschlüsselungsalgorithmus auch von beliebigen eines Vielzweck-Verarbeitungskerns, einer grafischen Verarbeitungseinheit, von FPGA, Einheiten künstlicher Intelligenz, Vernetzungschips usw. benutzt werden. Bei verschiedenen Ausführungsformen existiert somit eine API (Anwendungsprogrammierschnittstelle), die nicht nur zur Implementierung von SSD-Operationen aufrufbar ist, sondern auch Operationen für andere Hardwarekomponenten im Gesamtcomputer.
-
Man beachte, dass, um dabei zu helfen, das Hostsystem dabei zu unterstützen, aus Systemspeicher heraus und/alle oben erwähnten Funktionen, die traditionell innerhalb eines Solid-State-Drive ausgeführt wurden, auszuführen, ein Solid-State-Drive (einschließlich seines Controllers) dafür entworfen oder anderweitig ausgelegt werden kann, bestimmte Informationen zum Host zu senden (z.B. Statusinformationen, Bestätigung ausgeführter Befehle, Bestätigung von Nachrichtenempfängen usw.).
-
Als Letztes wird, obwohl die obigen Ausführungsformen Flash-Speicher-Massenspeicherungs-SSD erwähnt haben, bei noch anderen Ausführungsformen das nichtflüchtige Speicher-SSD mit einem dreidimensionalen nichtflüchtigen Direktzugriffsspeicher implementiert, der z.B. aus einer aufkommenden nichtflüchtigen Speicherungszellentechnologie zusammengesetzt ist. Beispiele wären Optane™-Speicher von der Intel Corporation, QuantX™ von der Micron Corporation und/oder andere Arten von resistiven nichtflüchtigen Speicherzellen, die zwischen der Interconnect-Verdrahtung eines Halbleiterchips (z.B. ReRAM (resistiver Direktzugriffsspeicher), FeRAM (ferroelektrischer Direktzugriffsspeicher), STT-RAM (Spin Transfer Torque Random Access Memory) usw.) integriert sind. Mindestens einige dieser Speicher sind byteadressierbar und können deshalb in einer Systemspeicherrolle verwendet werden, statt einer Massenspeicherungsrolle. Dementsprechend kann Firmware für Speichermodule zur Verwendung als nichtflüchtiger Systemspeicher auch extern von dem Speichermodul aus z.B. als eine nominale Softwareanwendung ausgeführt werden.
-
4 bietet eine beispielhafte Darstellung eines Datenverarbeitungssystems 400 (z. B. eines Smartphones, eines Tablet-Computers, eines Laptop-Computers, eines Desktop-Computers, eines Servercomputers usw.). Wie in 4 beobachtet, kann das Datenverarbeitungssystem 400 eine zentrale Verarbeitungseinheit (CPU) 401 (die z. B. mehrere universelle Verarbeitungskerne 415_1 bis 415_X umfassen kann) und eine Systemspeichersteuerung 417 (auch als eine Hauptspeichersteuerung bezeichnet), angeordnet auf einem Mehrkernprozessor oder Anwendungsprozessor, einen Hauptspeicher 402 (auch als Systemspeicher bezeichnet), eine Anzeige 403 (z. B. Touchscreen, Flachbild), eine lokale kabelgebundene Punkt-zu-Punkt-Verbindungsschnittstelle (z. B. USB) 404, verschiedene Netzwerk-E/A-Funktionen 405 (wie etwa eine Ethernet-Schnittstelle und/oder ein zellbasiertes Modemuntersystem), eine kabellose lokale Bereichsnetzwerkschnittstelle (z. B. WiFi) 406, eine kabellose Punkt-zu-Punkt-Verbindungsschnittstelle (z. B. Bluetooth) 407 und eine globale Positionsbestimmungssystemschnittstelle (GPS) 408, verschiedene Sensoren 409_1 bis 409_Y, eine oder mehrere Kameras 410, eine Batterie 411, eine Leistungsverwaltungseinheit 412, einen Lautsprecher und ein Mikrofon 413 und einen Audiocodierer/-decodierer 414 umfassen.
-
Ein Anwendungsprozessor oder Mehrkernprozessor 450 kann ein SOC sein, das einen oder mehrere Vielzweck-Verarbeitungskerne 415 in seiner CPU 401, eine oder mehrere grafische Verarbeitungseinheiten 416, einen Hauptspeicher-Controller 417 und eine E/A-Steuerfunktion 418 (Peripheral Control Hub) umfasst. Die Vielzweck-Verarbeitungskerne 415 führen typischerweise die System- und Anwendungssoftware des Datenverarbeitungssystems aus. Die Grafikverarbeitungseinheit 416 führt typischerweise grafikintensive Funktionen aus, um z.B. Grafikinformationen zu erzeugen, die auf der Anzeige 403 präsentiert werden. Das Datenverarbeitungssystem kann auch andere Arten von Verarbeitungseinheiten umfassen, die an den Kernen 415 tangential sind, wie etwa 1) eine Verarbeitungseinheit künstlicher Intelligenz zur Ausführung von Operationen auf Neuro-Netz-Synapsenbasis zum Lernen und Optimieren auf der Basis des Zustands; 2) mindestens eine umkonfigurierbare Verarbeitungseinheit, die aus einem Array von Speicherblöcken und Beschleunigern zusammengesetzt ist, um spezialisierte Operationen zu berechnen. Der Hauptspeicher-Controller 417 bildet eine Schnittstelle mit dem Systemspeicher 402 zum Schreiben/Lesen von Daten zu/von dem Systemspeicher 402.
-
Jeder aus dem Systemspeicher 402 und/oder dem nicht-flüchtigen Massenspeicher 420 kann mit einem dreidimensionalen nicht-flüchtigen Direktzugriffsspeicher zusammengesetzt sein, der z. B. aus einer aufkommenden nichtflüchtigen Speicherzellentechnologie zusammengesetzt ist. Beispiele umfassen Optane™-Speicher von Intel Corporation, QuantX™ von Micron Corporation und/oder andere Typen von resistiven nicht-flüchtigen Speicherzellen, integriert zwischen den Verbindungsbahnen eines Halbleiterchips (z. B. resistiven Direktzugriffsspeicher (ReRAM), ferroelektrischen Direktzugriffsspeicher (FeRAM), Spin-Transfer-Torque-Direktzugriffsspeicher (STT-RAM) usw.). Nichtflüchtiger Massenspeicher 420 kann zumindest auch aus Flash-Speicher zusammengesetzt sein (z. B. NAND-Flash). Ungeachtet des spezifischen nichtflüchtigen Speichertyps, der zur Massenspeicherung benutzt wird, kann wie oben beschrieben der nichtflüchtige Speicher in SSD integriert sein, deren Firmware wie oben ausführlich beschrieben wurde effektiv in Systemspeicher migriert hat.
-
Die Touchscreen-Anzeige 403, die Kommunikationsschnittstellen 404-407, die GPS-Schnittstelle 408, die Sensoren 409, die Kamera(s) 410 und der Lautsprecher/Mikrofon-Codec 413, 414 können allesamt als verschiedene Formen von E/A (Eingang und/oder Ausgang) bezüglich des Gesamtdatenverarbeitungssystems angesehen werden, umfassend, wo angemessen, auch eine integrierte periphere Vorrichtung (z. B. die eine oder mehreren Kameras 410). In Abhängigkeit von der Umsetzung können verschiedene dieser E/A-Komponenten auf dem Anwendungsprozessor/Mehrkernprozessor 450 integriert sein oder können sich außerhalb des Dies oder des Gehäuses des Anwendungsprozessors/Mehrkernprozessors 450 befinden. Die Leistungsverwaltungssteuereinheit 412 steuert im Allgemeinen den Leistungsverbrauch des Systems 400.
-
Obwohl die obige Besprechung von 4 die CPU 401, die grafische Verarbeitungseinheit bzw. grafischen Verarbeitungseinheiten 416, den Hauptspeicher-Controller 417 und den Peripheral Control Hub 418 als Komponenten eines SOC besprochen hat, versteht sich, dass die allgemeine Architektur von 4 auf beliebige von vielfältigen verschiedenen Arten von Datenverarbeitungssystemimplementierungen anwendbar ist. Zum Beispiel kann, um nur eine Möglichkeit zu nennen, der Computer von 4 auch als ein System mit Rack-Anbringung implementiert sein, wobei die CPU 401, der Hauptspeicher-Controller 417 und der Peripheral Control Hub 418 alle getrennte Komponenten sind, die in einen gemeinsamen Rack eingesteckt sind. Ein Beispiel ist eine OCP-Implementierung (Open Compute Project) oder dergleichen, z.B. für Raised-Floor- oder Datenzentralenanwendungen.
-
Ausführungsformen der Erfindung können verschiedene Prozesse umfassen, wie oben dargelegt. Die Prozesse können in maschinenausführbaren Anweisungen ausgeführt sein. Die Anweisungen können verwendet werden, um einen universellen oder speziellen Prozessor zu veranlassen, bestimmte Prozesse durchzuführen. Alternativ können diese Prozesse durch spezifische/maßgeschneiderte Hardwarekomponenten, die fest verdrahtete Logikschaltungsanordnungen oder programmierbare Logikschaltungsanordnungen (z. B. FPGA, PLD) zum Durchführen der Prozesse enthalten, oder durch eine beliebige Kombination aus programmierten Computerkomponenten und maßgeschneiderten Hardwarekomponenten durchgeführt werden.
-
Elemente der vorliegenden Erfindung können auch als ein maschinenlesbares Medium zum Speichern der maschinenlesbaren Anweisungen bereitgestellt sein. Das maschinenlesbare Medium kann, u. a., Floppy-Disketten, optische Platten, CD-ROMs und magneto-optische Platten, FLASH-Speicher, ROMs, RAMs, EPROMs, EEPROMs, magnetische oder optische Karten, Ausbreitungsmedien oder andere Typen von Medien/maschinenlesbaren Medien, die zum Speichern elektronischer Anweisungen geeignet sind, umfassen. Beispielsweise kann die vorliegende Erfindung als ein Computerprogramm heruntergeladen werden, das von einem entfernten Computer (z. B. einem Server) zu einem anfordernden Computer (z. B. einem Client) mittels Datensignalen, die in einer Trägerwelle ausgeführt sind, oder einem anderen Ausbreitungsmedium über eine Kommunikationsverbindung (z. B. eine Modem- oder Netzwerkverbindung) übertragen werden kann.
-
Es wurde ein Datenverarbeitungssystem beschrieben. Das Datenverarbeitungssystem umfasst mehrere Verarbeitungskerne; einen Systemspeicher-Controller; einen Peripheral Control Hub; ein mit dem Peripheral Control Hub gekoppeltes Solid-State-Drive; und einen mit dem Systemspeicher-Controller gekoppelten Systemspeicher. Der Systemspeicher umfasst Programmcode zum Ausführen von beliebigen des Folgenden in dem Solid-State-Drive: Abnutzungsnivellierung; Müllabfuhr; Übersetzung von LBA (logischer Blockadresse) in PBA (physische Blockadresse); die Verhandlung des Solid-State-Drive für Bandbreitenarbitrierung; Medienblock-Verpackung; Redundanz; Fehlerdetektion; Fehlerkorrektur; Datenauffrischung; Verschlüsselung; Konfiguration eines Hardwarebeschleunigers in dem Solid-State-Drive; Konfigurieren von Tiefe und/oder Dienstrate einer Warteschlange in dem Solid-State-Drive; und Snooping einer Befehlswarteschlange und Konsolidieren mehrerer Befehle für das Solid-State-Drive zu einem einzigen Befehl.
-
Der Programmcode soll Registerraum in dem Solid-State-Drive programmieren. Der Registerraum soll beliebiges von Folgendem implementieren: i) Freigeben eines Speicherchips in dem Solid-State-Drive; und ii) Freigeben eines statischen oder dynamischen Hardwarebeschleunigers in dem Solid-State-Drive. Der Registerplatz soll beliebiges von Folgendem implementieren: i) ob die Fehlerdetektion freizugeben ist; ii) welche Art der Fehlerdetektion anzuwenden ist; und ii) Controllerstatus oder Zustand, der freizugeben oder/und anzuwenden ist. Der Programmcode kann zur Ausführung durch beliebige der folgenden Hardwareeinheiten in dem Datenverarbeitungssystem geändert werden: einen Vielzweck-Verarbeitungskern; eine Grafikverarbeitungseinheit; ein FPGA (Field Programmable Gate Array); eine Einheit künstlicher Intelligenz; und eine Vernetzungseinheit.
-
Der Programmcode soll sequenziell Komponenten in dem Solid-State-Drive freigeben, um ein Treppen-Stromverbrauchsprofil durch das Solid-State-Drive während des Herauffahrens des Solid-State-Drive zu bewirken. Der Systemspeicher kann andere jeweilige Instanzen von Programmcode für andere Solid-State-Drives des Datenverarbeitungssystems umfassen. Der Programmcode und jede der Instanzen von Programmcode sind dafür ausgelegt, die Befehlswarteschlange ihres jeweiligen Solid-State-Drive für Software auf höherer Ebene zu exponieren. Das Datenverarbeitungssystem kann im Systemspeicher gespeicherten Lastausgleichs-Programmcode zum Favorisieren des Sendens von Speicherungsbefehlen zu denjenigen der Solid-State-Drives, deren Befehlswarteschlangen weniger belegt sind, über die der Solid-State-Drives, deren Befehlswarteschlangen mehr belegt sind, umfassen. Der Peripheral Control Hub kann beim Senden eines Lesebefehls oder Programmierbefehls zu dem Solid-State-Drive eine physischen Blockadresse zu dem Solid-State-Drive senden.
-
Es wird ein Verfahren beschrieben. Das Verfahren umfasst Ausführen von Programmcode von Solid-State-Drives aus Systemspeicher eines Datenverarbeitungssystems, um beliebige/alle der Folgenden für ein Solid-State-Drive, das mit dem Datenverarbeitungssystem gekoppelt ist, auszuführen: Abnutzungsnivellierung; Müllabfuhr; Übersetzung von LBA (logischer Blockadresse) in PBA (physische Blockadresse); die Verhandlung des Solid-State-Drive für Bandbreitenarbitrierung; Medienblock-Verpackung; Redundanz; Fehlerdetektion; Fehlerkorrektur; Datenauffrischung; Verschlüsselung; Konfiguration eines Hardwarebeschleunigers in dem Solid-State-Drive; Konfigurieren von Tiefe und/oder Dienstrate einer Warteschlange in dem Solid-State-Drive; und Snooping einer Befehlswarteschlange des Solid-State-Drive und Konsolidieren mehrerer Befehle für das Solid-State-Drive zu einem einzigen Befehl.
-
Das Ausführen des Solid-State-Drive-Programmcodes soll Registerraum in dem Solid-State-Drive programmieren. Die Programmierung des Registerraums soll Folgendes: i) Freigeben eines Speicherchips in dem Solid-State-Drive; und ii) Freigeben eines statischen oder dynamischen Hardwarebeschleunigers in dem Solid-State-Drive. Die Programmierung des Registerraums soll i) Fehlerdetektion ermöglichen; und ii) Ermitteln, welche Art von Fehlerdetektion anzuwenden ist. Die Programmierung des Registerraums soll i) Fehlerkorrekturcodierung ermöglichen; und ii) Ermitteln, welche Art von Fehlerkorrekturcodierung anzuwenden ist. Die Ausführung des Programmcodes bewirkt, dass Komponenten in dem Solid-State-Drive sequenziell freigegeben werden, um ein Treppen-Stromverbrauchsprofil durch das Solid-State-Drive während des Herauffahrens des Solid-State-Drive zu bewirken. Das Ausführen des Programmcodes exponiert die Befehlswarteschlange des Solid-State-Drive für Software auf höherer Ebene.
-
Das Verfahren kann ferner Exponieren jeweiliger Befehlswarteschlangen von Solid-State-Drives für die Software auf höherer Ebene mittels Ausführung ihrer jeweiligen Instanzen von Programmcode im Systemspeicher umfassen. Die Software auf höherer Ebene kann Senden von Speicherungsbefehlen zu denjenigen der Solid-State-Drives, deren Befehlswarteschlangen weniger belegt sind, über die der Solid-State-Drives, deren Befehlswarteschlangen mehr belegt sind, favorisieren. Das Verfahren kann ferner Senden eines Lesebefehls oder Programmierbefehls zu dem Solid-State-Drive mit einer physischen Blockadresse umfassen.
-
Es wurde eine Vorrichtung beschrieben. Die Vorrichtung umfasst ein Solid-State-Drive, das eine Anforderung von Informationen von einem Hostsystem, mit dem das Solid-State-Drive gekoppelt ist, empfangen soll. Die Informationen beschreiben den internen Kontext des Solid-State-Drive. Das Solid-State-Drive soll daraufhin intern die Informationen abrufen und die Informationen dann zu dem Hostsystem senden, um die Ausführung des Hostsystems von beliebigem des für das Solid-State-Drive ausgeführten Folgenden zu unterstützen: Abnutzungsnivellierung; Müllabfuhr; Übersetzung von LBA (logischer Blockadresse) in PBA (physische Blockadresse); die Verhandlung des Solid-State-Drive für Bandbreitenarbitrierung; Medienblock-Verpackung; Redundanz; Fehlerdetektion; Fehlerkorrektur; Datenauffrischung; Verschlüsselung; Konfiguration eines Hardwarebeschleunigers in dem Solid-State-Drive; Konfigurieren von Tiefe und/oder Dienstrate einer Warteschlange in dem Solid-State-Drive; und Snooping einer Befehlswarteschlange und Konsolidieren mehrerer Befehle für das Solid-State-Drive zu einem einzigen Befehl. Die Routinen der Müllabfuhr, Abnutzungsnivellierung und Übersetzung von logischer Blockadresse in physische Blockadresse sind durch Ausführen von Programmcode, der in Systemspeicher des Hostsystems instanziiert ist, mit einem Vielzweck-Verarbeitungskern des Hostsystems auszuführen.
-
In der vorstehenden Patentschrift wurde die Erfindung unter Bezugnahme auf spezifische Ausführungsbeispiele davon beschrieben. Es ist, allerdings, offensichtlich, dass verschiedene Modifikationen und Änderungen daran vorgenommen werden können, ohne vom breiteren Geist und Schutzumfang der Erfindung, wie in den beigefügten Ansprüchen dargelegt, abzuweichen. Die Spezifikation und Zeichnungen sind entsprechend in einem veranschaulichenden Sinne zu betrachten, nicht in einem einschränkenden Sinne.
