Freigeben über

Dirty-Bit-Nachverfolgung

  • Artikel

In diesem Artikel wird das Dirty-Bit-Nachverfolgungsfeature beschrieben, das ab Windows 11, Version 24H2 (WDDM 3.2) unterstützt wird. Treiber, die die Livemigration auf GPU-Parallelisierungsgeräten unterstützen, müssen auch die Dirty-Bit-Nachverfolgung unterstützen.

Einführung

Da GPUs in Cloudszenarien immer beliebter werden, muss zunehmend sichergestellt werden, dass bei der Migration virtueller Computer von einem physischen Host zu einem anderen eine angemessene Leistung erhalten bleibt. Dies ist nicht nur notwendig, um die Auswirkungen auf die Benutzer zu reduzieren, sondern auch, um Probleme wie Zeitüberschreitungen bei TCP-Anfragen zu vermeiden, wenn die VM migriert wird.

Das Übertragen von Speicherinhalten zwischen den physischen Hosts erfolgt in zwei Gesamtdurchläufen:

  1. Brownout: Während des Brownout-Zeitraums wird der virtuelle Computer noch ausgeführt, aber das System führt eine iterative Speicherung aller modifiziert Daten durch. Das Ziel ist, dass die Menge der bei jeder Iteration modifizierten Daten kleiner wird, bis sie auf eine kleinere Teilmenge von Daten konvergiert, die schnell kopiert werden kann. Diese Datenmenge variiert je nach Workload des Rechners und es wird nicht garantiert, dass sie auf eine bestimmte Größe konvergiert.

  2. Blackout: Während des Blackout-Zeitraums wird der virtuelle Computer angehalten, und die verbleibenden modifizierten Daten werden kopiert. Diese Kopie stellt sicher, dass sich die resultierenden Daten auf dem Zielcomputer im gleichen Zustand wie die Quelle befinden.

Ohne die Dirty-Bit-Nachverfolgung muss das System während des Blackout-Zeitraums eine einzelne vollständige Kopie des GPU-Framepuffers (VRAM) verwenden. Um den Brownout-Pass zu unterstützen, muss die Hardware in der Lage sein, modifizierte Speicherseiten aktiv zu verfolgen und an das Betriebssystem zurückzumelden, damit das Betriebssystem nur die Informationen dazu hat, welchen Speicher es kopieren muss.

Detailliertes Design

Berichtsfunktionen

Während der Adapterinitialisierung fragt Dxgkrnl den Treiber ab, um Informationen zum Format des von der Hardware verwendeten Dirty-Bitplane zu erhalten, nämlich die Seitengröße (oder die Datenmenge), die durch jedes Bit dargestellt wird.

Starten und Beenden der Erfassung modifizierter Daten

Wenn die Nachverfolgung modifizierter Informationen die Hardwareleistung erheblich beeinflusst, ist es sinnvoll, die Verfolgung modifizierter Informationen nur während des Brownout-Zeitraums zu aktivieren. In dieser Zeit ist die Minimierung der Kosten für die Migration wichtiger als die potenziellen Auswirkungen der Nachverfolgung auf die Leistung.

Wenn es jedoch überhaupt keine Auswirkungen auf die Leistung gibt, ist es vom Vorteil, dieses Verhalten immer zu aktivieren. Einige Benutzer führen möglicherweise keine schweren GPU-Workloads auf ihren virtuellen Computern aus, sodass der Arbeitsspeicher möglicherweise nicht von Anfang an stark modifiziert wird. Durch das Aktivieren der Dirty-Bit-Nachverfolgung zur Startzeit kann die erste Iteration des Brownouts die modifizierten Daten sofort verwenden, ohne dass eine vollständige Kopie des Framepuffers erforderlich ist. Wenn die Menge des vom Benutzer modifizierten Speichers klein ist (wenn der Benutzer beispielsweise in erster Linie CPU-Workloads durchführt), können die Kosteneinsparungen durch die Migration ganz erheblich sein. erheblich sein.

Abfragen von modifizierten Bits

Modifizierte Informationen werden als eine Bitplane von modifizierten Seiten dargestellt. Jedes Bit in der Bitplane stellt eine 'Seite' des Arbeitsspeichers dar. Die Seitengröße der modifizierten Daten muss nicht mit den natürlichen Seitengrößen der virtuellen Adressierung auf der GPU (z. B. 4 KB/64 KB) übereinstimmen. Es kann das sein, was für die jeweilige Hardware am besten geeignet ist. Der Treiber meldet diese Seitengröße während der Initialisierung.

Während des Brownout-Zeitraums fragt Dxgkrnl die Hardware nach modifizierten Daten zwischen den einzelnen Iterationen ab. Zu diesem Zeitpunkt muss der Treiber in der Lage sein, die Bitplane-Daten atomar abzufragen und zurückzusetzen. Das heißt, die Hardware muss in der Lage sein, den Wert abzufragen und in einem einzelnen atomaren Vorgang auf Null zurückzusetzen, um einen Datenverlust in den modifizierten Informationen zu verhindern.

Virtuelle Computer werden nicht unbedingt alle zum gleichen Ziel migriert, und daher erfolgt die Migration des Framepuffers für jede virtuelle GPU-Instanz einzeln. Der Treiber muss daher in der Lage sein, die Bitplane-Informationen für einen angegebenen Teilbereich des Gesamtframepuffers abzufragen, der diese bestimmte virtuelle GPU-Instanz darstellt. Eine 8-GB-GPU, die in vier Bereiche aufgeteilt ist, muss beispielsweise in der Lage sein, die Bits der Bitplane für jeden 2-GB-Bereich des VRAM einzeln abzufragen und zurückzusetzen, ohne die anderen Dirty-Bit-Daten zu beeinflussen.

DDI-Änderungen

Capabilities

Die folgenden Caps werden DXGK_QUERYADAPTERINFOTYPE hinzugefügt.

Speicherbasis-DDIs

Die Verfolgung von Änderungsoperationen auf VRAM ist für Zuweisungen gedacht, die möglicherweise nicht zusammenhängend gesichert werden. Eine anfängliche Verwendung in der Livemigration gilt z. B. für die Nachverfolgung der Framebuffer-Reserve für eine virtuelle Funktion. Die physischen Adressen, die in der Nachverfolgung von modifizierten Bits dargestellt werden, bestehen also aus einer Sammlung von Bereichen, die die zu verwendende Zuordnung darstellen.

Es ist wichtig, sicherzustellen, dass die Vorgänge mit denselben Bereichen übereinstimmen. In vielen Fällen muss dieser Abgleich eine erzwungene Invariante der Schnittstellen sein, um eine ordnungsgemäße Nachverfolgung des Zustands sicherzustellen. Zur Unterstützung dieser Nachverfolgung mit dem KMD werden die folgenden Schnittstellen eingeführt: