Compartilhar via


Rastreamento de bits sujos

Este artigo descreve o recurso de rastreamento de bits sujos, que é suportado a partir do Windows 11, versão 24H2 (WDDM 3.2). Os drivers que oferecem suporte à migração ao vivo em dispositivos de paralelização de GPU também devem oferecer suporte ao rastreamento de bits sujos.

Introdução

À medida que as GPUs em cenários de nuvem se tornam mais populares, há uma necessidade crescente de garantir que a migração de máquinas virtuais de um host físico para outro mantenha um desempenho razoável. Essa necessidade não é apenas para reduzir o impacto do usuário, mas também para evitar problemas como tempos-limite de solicitação TCP à medida que a VM é migrada.

A transferência de conteúdo de memória entre os hosts físicos é feita em duas passagens gerais:

  1. Blecaute parcial: durante o período de blecaute parcial, a máquina virtual ainda está em execução, mas o sistema executa um salvamento iterativo de todos os dados sujos. O objetivo é que a quantidade de dados sujos durante cada iteração fique menor até convergir em um subconjunto menor de dados que possa ser copiado rapidamente. Essa quantidade de dados varia dependendo da carga de trabalho da máquina, e não é garantido que convirja para qualquer tamanho específico.

  2. Blecaute: durante o período de blecaute, a máquina virtual é pausada, e todos os dados sujos restantes são copiados. Essa cópia garante que os dados resultantes na máquina de destino estejam no mesmo estado que a origem.

Sem rastreamento de bits sujos, o sistema deve contar com uma única cópia completa do buffer de quadros (VRAM) da GPU durante o período de blecaute. Para suportar o período de blecaute parcial, o hardware deve ser capaz de rastrear ativamente páginas de memória sujas e relatá-las ao sistema operacional para que o sistema operacional saiba apenas qual memória copiar.

Projeto detalhado

Recursos de relatórios

Durante a inicialização do adaptador, o Dxgkrnl consulta o driver para pedir informações sobre o formato do plano de bits sujos usado pelo hardware, ou seja, o tamanho da página (ou quantidade de dados) representado por cada bit.

Iniciar e parar a captura suja

Se o rastreamento de informações sujas tem um alto custo no desempenho do hardware, então faz sentido habilitar apenas o rastreamento sujo durante o período de blecaute parcial. Durante esse tempo, minimizar os custos de migração é mais importante do que o impacto potencial do rastreamento no desempenho.

No entanto, se houver um impacto insignificante ou nenhum impacto no desempenho, há um benefício em sempre habilitar esse comportamento. Alguns usuários podem não executar cargas de trabalho pesadas de GPU em suas VMs, portanto, a memória pode não estar muito suja desde o início. Ao habilitar o rastreamento de bits sujos no momento da inicialização, a primeira iteração do blecaute parcial pode usar imediatamente os dados sujos sem a necessidade de uma cópia completa do buffer de quadros. Se a quantidade de memória suja pelo usuário for pequena (por exemplo, o usuário estiver trabalhando principalmente com cargas de trabalho de CPU), a economia de custos da migração pode ser bastante significativa.

Consultar bits sujos

A informação suja é representada como um plano de bits de páginas sujas. Cada bit no plano de bits representa uma "página" de memória. O tamanho da página dos dados sujos não precisa estar alinhado aos tamanhos naturais das páginas do endereçamento virtual na GPU (por exemplo, 4KB/64KB). Pode ser o que for mais ideal para o hardware específico. O driver relata esse tamanho de página durante a inicialização.

Durante o período de blecaute parcial, o Dxgkrnl consulta o hardware em busca de dados sujos entre cada iteração. Neste momento, o driver deve ser capaz de consultar e redefinir atomicamente os dados do plano de bits. Ou seja, o hardware deve ser capaz de consultar o valor e redefini-lo para zero em uma única operação atômica para evitar uma perda de dados nas informações sujas.

As máquinas virtuais não são necessariamente todas migradas para o mesmo destino e, portanto, a migração do buffer de quadros ocorre para cada instância de GPU virtual. O driver deve, portanto, ser capaz de consultar as informações do plano de bits para um subintervalo especificado do buffer de quadros geral que representa essa instância de GPU virtual específica. Por exemplo, uma GPU de 8 GB dividida de quatro maneiras deve ser capaz de consultar e redefinir individualmente os bits do plano de bits para cada intervalo de 2 GB de VRAM separadamente sem afetar os outros dados de bits sujos.

Alterações de DDI

Funcionalidades

As seguintes tampas são adicionadas ao DXGK_QUERYADAPTERINFOTYPE.

DDIs de base de memória

O rastreamento de operações de modificação na VRAM é para alocações que podem não ter respaldo contíguo. Um uso inicial na migração ao vivo, por exemplo, se aplica ao rastreamento na reserva de buffer de quadros para uma função virtual. Assim, os endereços físicos representados no rastreamento de bits sujos consistem em uma coleção de intervalos que representam a alocação que está sendo operada.

É importante garantir que as operações correspondam aos mesmos intervalos. Em muitos casos, essa correspondência precisa ser uma invariante imposta das interfaces para garantir o rastreamento adequado do estado. Para auxiliar esse rastreamento com o KMD, as seguintes interfaces são introduzidas: