Condividi tramite

Rilevamento dei bit dirty

  • Articolo

Questo articolo descrive la funzionalità di rilevamento dei bit dirty, supportata a partire da Windows 11 versione 24H2 (WDDM 3.2). I driver che supportano la migrazione in tempo reale nei dispositivi di parallelizzazione GPU devono supportare anche il rilevamento dei bit dirty.

Introduzione

Man mano che le GPU negli scenari cloud diventano più diffuse, è necessario assicurarsi che la migrazione di macchine virtuali da un host fisico a un altro mantenga prestazioni ragionevoli. Questa esigenza non è solo per ridurre l'impatto dell'utente, ma anche per evitare problemi come i timeout delle richieste TCP durante la migrazione della macchina virtuale.

Il trasferimento del contenuto della memoria tra gli host fisici viene eseguito in due passaggi complessivi:

  1. Brownout: durante il periodo brownout, la macchina virtuale è ancora in esecuzione, ma il sistema esegue un salvataggio iterativo di tutti i dati dirty. L'obiettivo è che la quantità di dati deviati durante ogni iterazione diventa più piccola fino a quando non converge su un subset di dati più piccolo che può essere copiato rapidamente. Questa quantità di dati varia a seconda del carico di lavoro del computer e non è garantita la convergenza a una dimensione specifica.

  2. Blackout: durante il periodo di black-out, la macchina virtuale viene sospesa e tutti i dati dirty rimanenti vengono copiati. Questa copia garantisce che i dati risultanti nel computer di destinazione siano nello stesso stato dell'origine.

Senza il rilevamento dei bit dirty, il sistema deve basarsi su una singola copia completa del buffer dei fotogrammi della GPU (VRAM) durante il periodo di black-out. Per supportare il passaggio brownout, l'hardware deve essere in grado di tenere traccia attivamente delle pagine di memoria sporte e di riportarlo al sistema operativo in modo che il sistema operativo conosca solo la memoria da copiare.

Progettazione dettagliata

Funzionalità di reporting

Durante l'inizializzazione dell'adattatore, Dxgkrnl esegue una query sul driver per chiedere informazioni sul formato del bitplano dirty usato dall'hardware, ovvero le dimensioni della pagina (o la quantità di dati) rappresentate da ogni bit.

Avvio e arresto dell'acquisizione dirty

Se il rilevamento delle informazioni dirty ha un costo elevato sulle prestazioni dell'hardware, è opportuno abilitare solo il rilevamento dirty durante il periodo brownout. Durante questo periodo, ridurre al minimo i costi della migrazione è più importante rispetto al potenziale impatto sulle prestazioni del rilevamento.

Tuttavia, se non c'è alcun impatto trascurabile o negativo sulle prestazioni, c'è un vantaggio per abilitare sempre questo comportamento. Alcuni utenti potrebbero non eseguire carichi di lavoro GPU pesanti nelle macchine virtuali, quindi la memoria potrebbe non essere pesantemente sporsa dall'inizio. Abilitando il rilevamento dei bit dirty in fase di avvio, la prima iterazione del brownout può usare immediatamente i dati dirty senza la necessità di una copia completa del buffer dei frame. Se la quantità di memoria deviata dall'utente è ridotta (ad esempio, l'utente esegue principalmente carichi di lavoro della CPU), il risparmio sui costi della migrazione può essere piuttosto significativo.

Esecuzione di query su bit dirty

Le informazioni dirty sono rappresentate come un bitplane di pagine dirty. Ogni bit nel piano di bit rappresenta una "pagina" di memoria. Le dimensioni della pagina dei dati dirty non devono essere allineate alle dimensioni delle pagine naturali dell'indirizzamento virtuale nella GPU (ad esempio, 4 KB/64 KB). Può essere ciò che è più ottimale per l'hardware specifico. Il driver segnala le dimensioni della pagina durante l'inizializzazione.

Durante il periodo brownout, Dxgkrnl esegue una query sull'hardware per individuare i dati dirty tra ogni iterazione. Al momento, il driver deve essere in grado di eseguire query atomicamente e reimpostare i dati bitplane. Ovvero, l'hardware deve essere in grado di eseguire query sul valore e reimpostarlo su zero in una singola operazione atomica per evitare una perdita di dati nelle informazioni dirty.

Le macchine virtuali non sono necessariamente tutte migrate alla stessa destinazione e pertanto la migrazione del buffer dei frame avviene per ogni istanza della GPU virtuale. Il driver deve quindi essere in grado di eseguire una query sulle informazioni del bitplane per un intervallo secondario specificato del buffer di frame complessivo che rappresenta quella particolare istanza della GPU virtuale. Ad esempio, una GPU da 8 GB suddivide quattro modi deve essere in grado di eseguire query singolarmente e reimpostare i bit del bitplane per ogni intervallo di 2 GB di VRAM separatamente senza influire sugli altri dati di bit dirty.

Modifiche DDI

Funzionalità

I limiti seguenti vengono aggiunti a DXGK_QUERYADAPTERINFOTYPE.

  • DXGKQAITYPE_DIRTYBITTRACKINGC piattaforma di strumenti analitici

    Il sistema chiama ora la funzione DxgkDdiQueryAdapterInfo di KMD con una DXGK_QUERYADAPTERINFOTYPE di DXGKQAITYPE_DIRTYBITTRACKINGC piattaforma di strumenti analitici durante l'inizializzazione dell'adattatore per determinare le funzionalità hardware e driver per il rilevamento dei bit dirty.

    Il kmD deve compilare la struttura di DXGK_DIRTY_BIT_TRACKING_C piattaforma di strumenti analitici fornita a cui punta pOutputData.

  • DXGKQAITYPE_DIRTYBITTRACKING edizione Standard GMENTC piattaforma di strumenti analitici

    Se KMD imposta DirtyBitTrackingSupported su TRUE, il sistema chiama la funzione DxgkDdiQueryAdapterInfo del KMD con un DXGK_QUERYADAPTERINFOTYPE di DXGKQAITYPE_DIRTYBITTRACKING edizione Standard GMENTC piattaforma di strumenti analitici per ogni segmento di memoria nel sistema per eseguire query sul supporto del rilevamento dei bit dirty.

    Il kmD deve compilare la struttura di DXGK_DIRTY_BIT_TRACKING_edizione Standard GMENT_C piattaforma di strumenti analitici fornita a cui punta pOutputData.

DDI di base della memoria

Il rilevamento delle operazioni di modifica in VRAM riguarda le allocazioni che potrebbero non essere supportate in modo contiguo. Un uso iniziale in Live Migration, ad esempio, si applica al rilevamento nella riserva framebuffer per una funzione virtuale. Gli indirizzi fisici rappresentati nel rilevamento dei bit dirty sono quindi costituiti da una raccolta di intervalli che rappresentano l'allocazione utilizzata.

È importante assicurarsi che le operazioni corrispondano agli stessi intervalli. In molti casi, questa corrispondenza deve essere un'invariante applicata delle interfacce per garantire un corretto rilevamento dello stato. Per facilitare questo rilevamento con il KmD, sono state introdotte le interfacce seguenti: