O Linux 7.3 melhora a performance quando falta VRAM na GPU

Depois de meses circulando em listas de discussão do kernel, patches que melhoram o gerenciamento de VRAM em GPUs AMD foram finalmente mesclados upstream e estão na fila para o Linux↳Linux34 conteúdosKali Linux em um Servidor VPS: como, quando e por que usar?DevSecOps · dez 2024Construindo um Windows Service ou Linux Daemon com Worker Service & .NET Core – Parte 2Dev (Back & Front) · jul 2020Criando uma WebApi utilizando .NET, Linux e VSCodeDev (Back & Front) · ago 2019Ver tudo em DevSecOps → 7.3. O trabalho, documentado pelo desenvolvedor conhecido como pixelcluster, ataca um problema clássico: o que acontece quando uma aplicação pede mais memória de vídeo do que a placa fisicamente tem.

O problema do overcommit de VRAM

O suporte a overcommit de VRAM existe desde sempre nos drivers de GPU: você pode requisitar mais memória do que existe, e o driver decide o que cabe na memória física da placa. Quando estoura, parte da memória do processo é despejada (evicted) para a RAM da CPU.

O custo disso é físico. Para o GPU, acessar RAM da CPU é muito mais lento que a VRAM, porque tudo passa pelo barramento PCI, que adiciona latência e limita a banda. Segundo os cálculos do autor, numa conexão PCIe 4.0 x16 você tem pouco menos de 32 GiB/s, ou cerca de 32,2 MiB por milissegundo. Para manter 30 FPS (33,3 ms por quadro), o teto absoluto de dados vindos de memória despejada é de aproximadamente 1 GiB por quadro. Ultrapassou isso, e é matematicamente impossível segurar os 30 FPS.

Mas nem toda memória pesa igual. Acessos que caem bem em cache amortizam boa parte do custo do PCIe: se o dado couber na L2, a latência é idêntica esteja ele na CPU ou na VRAM. O autor mediu, em RDNA3, que uma busca via PCIe tem cerca de 7,3x mais latência que um hit na Infinity Cache e 4,6x mais que uma busca na VRAM. Ou seja, ficar sem VRAM deveria ser, em teoria, só um problema de performance, não de estabilidade.

Na prática, faltava estabilidade

A teoria bateu de frente com a realidade assim que o autor tentou rodar um jogo no SteamOS com as configurações no talo:

radv/amdgpu: Not enough memory for command submission.

O detalhe importante é que o erro reclama de command submission, não de alocação. Todos os buffers já tinham sido alocados com sucesso. O problema era que, ao submeter comandos, o kernel retornava -ENOMEM.

A causa está no locking do kernel. Antes de mandar a GPU executar, o driver amdgpu garante que toda a memória potencialmente referenciada esteja acessível. Certas alocações precisam obrigatoriamente estar na VRAM e, se foram despejadas, têm de voltar, o que exige despejar algo mais. Quando duas submissões concorrentes tentam travar as alocações uma da outra, surge um clássico deadlock ABBA.

O kernel sabe resolver isso: ele marca uma das transações como wounded e devolve -EDEADLCK, pedindo que ela reinicie do zero. No subsistema gráfico, esse laço de wound-abort-retry é abstraído pela biblioteca drm_exec. O problema é que o TTM, a camada compartilhada de gerenciamento de memória de GPU no Linux, não usava esse helper. Havia até um comentário no código anotando que -EDEADLCK faria a eviction falhar, exatamente o bug encontrado.

Existiam patches para conectar o drm_exec ao TTM enviados desde 2024, mas que nunca entraram por causa de bugs remanescentes. O autor rebaseou o patchset e caçou os problemas restantes, o que segundo ele custou "uma única semana de sofrimento intenso com jogos travando aleatoriamente 3 minutos depois de contenção pesada de VRAM". Parte desse trabalho ainda precisa de refino antes do merge final.

O ping-pong de memória e a saída de scanout

Resolvida a estabilidade, restava a performance, que estava péssima. Usando o gpuvis, que monta uma linha do tempo a partir de tracepoints do kernel, o autor descobriu que a maior parte do tempo não era gasta processando a submissão, mas movendo memória de um lado para outro (atividade sdma0) para preparar a submissão.

O padrão era um ping-pong: processos concorrentes, como o gamescope e o próprio jogo, ficavam se revezando para despejar e trazer de volta o mesmo pedaço de memória, repetidamente. Isso reintroduziu, via proteção de VRAM com dmem cgroups, um problema que já tinha sido resolvido antes.

O vilão principal é o buffer de scanout, a imagem que vai para o display. Esse buffer precisa estar na VRAM e, pior, contíguo em memória física, porque o hardware de display ignora a memória virtual e trabalha com endereços físicos. O algoritmo de eviction do kernel, porém, não considera contiguidade física. Ele é um laço simplório:

while (true) {
  evict(getLeastRecentlyUsedBuffer())
  if (tryAllocate(newBuffer) == SUCCESS)
    break;
}

Com a VRAM fragmentada, achar um bloco contíguo grande o bastante pode exigir despejar quase tudo. O autor relata ter observado até 4 GiB de VRAM sendo despejados só para acomodar imagens de scanout de cerca de 32 MiB (formato R11G11B10). Só o custo de tirar esses 4 GiB da VRAM já seria de aproximadamente 130 ms, pela taxa de transferência do PCIe.

A solução por heurísticas

A correção veio na forma de heurísticas de throttle. Quando o kernel detecta que a memória de uma aplicação está sendo despejada, ele entra numa fase de hard throttle por alguns milissegundos, durante a qual não tenta trazer nada de volta para a VRAM. Em seguida vem uma fase de soft throttle, de até alguns segundos, na qual ele pode reocupar espaço livre, mas sem despejar memória de outros apps. Se essa fase terminar sem novas evictions, o sistema é considerado estável.

A proteção via dmem cgroup não resolve tudo sozinha, mas reduz muito o escopo: garante que um app qualquer não expulse recursos importantes de um jogo à toa.

O que isso muda para o dev brasileiro

O ângulo mais imediato é gaming em Linux e SteamOS, e a base de jogadores rodando Proton no Brasil só cresce. Mas a discussão toca em algo maior para quem trabalha com infraestrutura e virtualização: o gerenciamento de memória de GPU no kernel afeta diretamente cargas de GPU compartilhada, cada vez mais comuns em cenários de inferência de modelos, renderização e VMs com passthrough.

A lógica de eviction, deadlock e contiguidade física descrita aqui é a mesma que aparece quando múltiplas cargas disputam uma GPU num servidor. Ter o drm_exec chegando ao TTM e heurísticas de throttle no kernel significa comportamento mais previsível sob pressão de memória, o que é exatamente o tipo de estabilidade que times de DevOps precisam quando dimensionam GPU em cloud ou on-premises.

Fica em aberto, porém, uma parte relevante: nem todo o patchset foi mesclado. O autor deixou claro que os patches de drm_exec no TTM ainda precisam de mais trabalho antes de entrarem. O que chega garantido ao Linux 7.3 é a base do gerenciamento de VRAM; o resto continua na fila das listas de discussão do kernel.

Fonte: Hacker News