Partager via

Suivi des bits sales

  • Article

Cet article décrit la fonctionnalité de suivi des bits sales, qui est prise en charge à partir de Windows 11, version 24H2 (WDDM 3.2). Les pilotes qui prennent en charge la migration en direct sur les appareils de parallélisation GPU doivent également prendre en charge le suivi des bits sales.

Introduction

À mesure que les GPU deviennent plus populaires dans les scénarios de cloud, il est de plus en plus nécessaire de s'assurer que la migration des machines virtuelles d'un hôte physique à un autre maintient des performances raisonnables. Il ne s'agit pas seulement de réduire l'impact sur l'utilisateur, mais aussi d'éviter les problèmes tels que les dépassements de délai des requêtes TCP lors de la migration de la machine virtuelle.

Le transfert du contenu de la mémoire entre les hôtes physiques s'effectue en deux passes globales :

  1. Brownout : Pendant la période d'arrêt, la machine virtuelle continue de fonctionner, mais le système effectue une sauvegarde itérative de toutes les données sales. L'objectif est de réduire la quantité de données salies à chaque itération jusqu'à ce que le système converge vers un sous-ensemble de données plus petit qui peut être copié rapidement. Cette quantité de données varie en fonction de la charge de travail de la machine et il n'est pas garanti qu'elle converge vers une taille particulière.

  2. Période d'interdiction : Pendant la période d'interdiction, la machine virtuelle est mise en pause et toutes les données sales restantes sont copiées. Cette copie garantit que les données résultantes sur la machine de destination sont dans le même état que la source.

Sans suivi des bits sales, le système doit s'appuyer sur une seule copie complète du frame buffer (VRAM) du GPU pendant la période de blackout. Pour prendre en charge le passage au brownout, le matériel doit être en mesure de suivre activement les pages de mémoire encrassées et de le signaler au système d'exploitation afin que ce dernier sache uniquement quelle mémoire copier.

Conception détaillée

Fonctionnalités de création de rapports

Lors de l'initialisation de l'adaptateur, Dxgkrnl interroge le pilote pour lui demander des informations sur le format du plan de bits sales utilisé par le matériel, à savoir la taille de la page (ou la quantité de données) représentée par chaque bit.

Démarrage et arrêt de la capture des données sales

Si le suivi des informations sales a un coût élevé sur les performances du matériel, il est logique de n'activer le suivi des informations sales que pendant la période de panne. Pendant cette période, la minimisation des coûts de migration est plus importante que l'impact potentiel du suivi sur les performances.

Toutefois, si l'impact sur les performances est négligeable ou nul, il est avantageux de toujours activer ce comportement. Certains utilisateurs n'effectuent pas de charges de travail GPU importantes sur leurs machines virtuelles, de sorte que la mémoire n'est pas forcément très sale dès le départ. En activant le suivi des bits sales au démarrage, la première itération du brownout peut immédiatement utiliser les données sales sans avoir besoin d'une copie complète du frame buffer. Si la quantité de mémoire utilisée par l'utilisateur est faible (par exemple, si l'utilisateur effectue principalement des charges de travail processeur), les économies réalisées grâce à la migration peuvent être considérables.

Interrogation des bits sales

Les informations sales sont représentées sous la forme d'un plan binaire de pages sales. Chaque bit du plan binaire représente une "page" de mémoire. La taille de la page des données sales n'a pas besoin d'être alignée sur la taille naturelle des pages de l'adressage virtuel sur le GPU (par exemple, 4KB/64KB). Elle peut être la plus optimale pour le matériel en question. Le pilote indique cette taille de page lors de l'initialisation.

Pendant la période de ralentissement, Dxgkrnl demande au matériel s'il y a des données sales entre chaque itération. À ce moment-là, le pilote doit être en mesure d'interroger et de réinitialiser les données du plan de bits de manière atomique. En d'autres termes, le matériel doit être en mesure d'interroger la valeur et de la remettre à zéro en une seule opération atomique afin d'éviter toute perte de données dans les informations sales.

Les machines virtuelles ne sont pas nécessairement toutes migrées vers la même destination, et la migration du frame buffer se produit donc pour chaque instance de GPU virtuel. Le pilote doit donc être en mesure d'interroger les informations relatives au plan de bits pour une sous-gamme spécifiée du tampon de trame global qui représente cette instance de GPU virtuel particulière. Par exemple, un GPU de 8 Go divisé en quatre doit pouvoir interroger et réinitialiser individuellement les bits du plan de bits pour chaque plage de 2 Go de VRAM sans affecter les autres données de bits sales.

Modifications DDI

Fonctionnalités

Les caps suivants sont ajoutés à DXGK_QUERYADAPTERINFOTYPE.

DDI de base de la mémoire

Le suivi des opérations de modification sur la VRAM concerne les allocations qui peuvent ne pas être sauvegardées de manière contiguë. Une première utilisation dans la migration en direct, par exemple, s'applique au suivi de la réserve du framebuffer pour une fonction virtuelle. Ainsi, les adresses physiques représentées dans le suivi des bits sales consistent en une collection de plages représentant l'allocation en cours d'exploitation.

Il est important de s'assurer que les opérations correspondent aux mêmes plages. Dans de nombreux cas, cette correspondance doit être un invariant forcé des interfaces pour garantir un suivi correct de l'état. Pour faciliter ce suivi avec le KMD, les interfaces suivantes sont introduites :