Am Ende hängen gerade die sequentiellen Zugriffe auch unmittelbar davon ab wie schnell (Latenz!) die CPU dem NVMe-Gerät lesenden und schreibenden Zugriff auf den RAM geben kann - und in der Disziplin ist die im Test verwendete Intel-Server-CPU weit abgeschlagen. Das kann zwar eine SSD mit Onboard-RAM gut maskieren (die Lexmar NM1090 Pro hat keinen!), aber ein guter Cache auf der CPU bringt hier im Gesamtsystem mehr.
Moment, die SSDs mit DRAM Cache brauchen keinen HMB, der bei denen ohne DRAM Cache eine Krücke ist um das Fehlen des Cache für die Metadaten des Controllers etwas abzumildern. Die verwendete Xeon W9-3495X hat 105MB Cache, daran dürfte es nicht liegen, zumal bei den Tests die nur über 1GB Adressraum gehen, denn die Metadaten für 1GB Adressraum können die DRAM less Controller im internen SRAM vorhalten.
insbesondere bekommt der Controller jetzt potentiell wesentlich mehr einzelne Updates für seine Queues (pro CPU-Kern wird eine verwendet, und jetzt wird auch kein aggressives Batching mehr gemacht!)
Dann würde ich eher die Synchronisierung der Threads als Ursache ansehen, denn es muss ja sichergestellt werden, dass nicht zwei Threads die gleiche Adresse überschreiben wollen, denn dann wäre es reiner Zufall wer zuerst zum Zug kommt und damit was dort hinterher steht. Dies dürfte bei der verwendeten CPUs länger dauern als bei einer Desktop CPU mit viel weniger Kernen.
In der Gegenrichtung sollte die NVMe auch nicht pro Kommando einen eigenen Interrupt auf der CPU auslösen, sondern nur wenn der Zustand der IO-Completion-Queue explizit zwischen "leer" und "nicht-leer" wechselt,
Doch, die SSDs müssen natürlich die CPU über das Ende der Ausführung eines Befehls informieren, denn wäre es wie Du es Dir wünscht, könnte es dazu kommen, dass eine Daten schon vor einer Ewigkeit gelesen hat, aber dies nicht meldet bis die ganze Queue leer ist und dann wäre die Performance total mies, weil letzteres vielleicht erst nach Minuten der Fall ist und die CPU so lange nicht erfahren würde, dass die ganzen Aufträge von vorher schon abgearbeitet wurden.
manche ältere NVMe-Controller spamen die CPU proportional zur Anzahl der selbst empfangenen Kommandos zu.
Jede Wette das dies auch die neusten machen, denn es wäre schlimm wenn nicht, da die CPU dann nicht wüsste, dass ein Befehl abgearbeitet wurde und das Programm welche Daten angefordert hat, dann immer noch warten würde, wenn diese schon lange übertragen wurden. Es werden übrigens normalerweise keine Hardware Interrupts verwendet, sondern Message Signaled Interrupts.
Viele Probleme treten auf, wenn die SSDs keine Power-loss-Protection unterstützen. Dann werden die Schreibzugriffe erst bestätigt, wenn diese tatsächlich vollständig geschrieben sind und das zieht die Performance massiv in den Keller.
Ja, aber nur wenn man den
Schreibcache auf der SSD deaktiviert, was dann aber z.B. bei AS-SSD zu ein bis maximal niedrigen zweistellen MB/s bei 4k Schreibend erzeugt. Enterprise SSDs mit PLP ignorieren dies, bzw. Fake eben die Bestätigung das die Daten aufs Medium geschrieben wurden, da sie dies ja auch bei einem unerwarteten Spannungsabfall noch machen können.
Enterprise SSDs haben das Feature. Consumer SSDs können das Feature haben oder eben nicht.
Die einzigen Consumer SSDs die wirklich eine PLP hatten, waren einige Intel wie die 730 und 750, die eigentlich Enterprise SSDs waren und die Optane, die direkt ins 3D XPoint geschrieben haben, Userdaten wie auch die Mappingtabelle und daher keinen DRAM Cache brauchen und trotzdem so schnell sind als hätten sie einen. Ansonsten gab es ein paar z.B. von Crucial die eine kleine PLP Lösung hatten, aber deren Kondensatoren waren so klein, dass sie nur die Verwaltungsdaten abgesichert haben, nicht die Userdaten.
Mit der Performance des neuen NVMe Treibers hat das Thema PLP aber nichts zu tun.
