A NVIDIA enviou uma nova série de patches para o Kernel Linux 7.3 com um objetivo bastante específico: alterar o comportamento do agendador de tarefas (scheduler) para impedir o desperdício de ciclos de processamento em seus núcleos Olympus, base da plataforma Vera. A mudança, assinada pelo engenheiro Andrea Righi, corrige um gargalo na forma como o sistema operacional lida com o Simultaneous Multithreading (SMT) nesses chips, garantindo saltos na casa dos Teraflops em tarefas de alta demanda.
O envio escancara o nível de micro-otimização necessário no desenvolvimento de hardware para computação de alto desempenho (HPC) e inteligência artificial, onde acordar uma thread no momento errado pode custar caro para o desempenho geral do servidor.
O problema: o custo oculto de acordar uma thread
Para entender a mudança, é preciso olhar para a arquitetura dos núcleos Olympus. Cada núcleo físico é composto por dois elementos de processamento simétricos: PE0 e PE1.
O comportamento esperado em processadores modernos é que, quando apenas um elemento (como o PE0) está ativo, ele utilize 100% dos recursos do núcleo em modo single-thread. Se o sistema operacional enviar uma tarefa para o PE1, o núcleo entra em modo two-thread, dividindo os recursos.
O problema no silício da NVIDIA é o custo de transição. Segundo a documentação enviada ao Kernel Linux, o design Olympus é extremamente sensível a “microativações”. Se o agendador do Linux enviar uma tarefa rápida para o PE1, o PE0 perde capacidade instantaneamente.
A pior parte ocorre quando a tarefa do PE1 termina. A devolução dos recursos não é imediata. O núcleo impõe um “intervalo de qualificação” — exatos 10.000 ciclos no sistema Vera testado — em que o PE1 precisa permanecer em estado de espera (WFI) antes que o PE0 possa voltar a usar 100% do poder computacional. Na prática, se o Linux ficar alternando pequenas tarefas entre os dois elementos, o núcleo nunca atinge seu potencial máximo.
A solução: forçar um “irmão favorito” no agendador
A estratégia de Righi para contornar essa característica física do chip foi ensinar ao Linux o conceito de “prioridade assimétrica de SMT” (SD_ASYM_PACKING).
Como ambos os elementos têm a mesma capacidade teórica, não há um lado mais rápido. A solução foi puramente lógica: transformar o PE0 em uma escolha canônica. Os patches alteram as regras de seleção de inatividade do fair scheduler (agendador justo) do Kernel Linux. Agora, ao procurar um núcleo ocioso para despachar uma tarefa comum, o sistema sempre vai preferir o PE0.
Ao concentrar o trabalho de forma consistente no mesmo elemento, o PE1 permanece ocioso por períodos muito maiores, evitando o penalizador ciclo de reconfiguração de 10.000 ciclos e mantendo a máquina em capacidade total por mais tempo.
Os bastidores: por que a NVIDIA está dissecando o agendador?
Essa movimentação no código-fonte revela o grau de maturidade da estratégia de hardware da NVIDIA. Os arquivos modificados pelos patches (arch/arm64/kernel/topology.c) confirmam que o foco da otimização é a arquitetura ARM de 64 bits.
Com a adoção agressiva de processadores baseados em ARM (como as linhas Grace e, agora, chips com núcleos Olympus e plataformas Vera/Rigel) em data centers e supercomputadores, a NVIDIA não pode depender apenas de drivers de vídeo proprietários. A empresa precisa que o próprio coração do Kernel Linux extraia o máximo de sua arquitetura de CPU.
Em cargas de trabalho voltadas para inteligência artificial especialmente operações matemáticas massivas em matrizes, qualquer flutuação no agendador destrói a eficiência energética e térmica do rack. Ter engenheiros seniores como Andrea Righi (que já trabalhou na Canonical) focados em alinhar o comportamento do agendador nativo do Linux às idiossincrasias físicas do silício da NVIDIA é um passo fundamental para disputar espaço de igual para igual com soluções tradicionais x86 (Intel e AMD) em servidores.
Impacto nos benchmarks: de 6.2 para mais de 10 TFLOP/s
A otimização provou seu valor em números práticos. A NVIDIA testou as mudanças em um sistema Vera de dois nós, executando um benchmark GEMM (General Matrix Multiply) de precisão simples com 88 threads, fixado em 88 núcleos físicos.
Esse ganho ocorreu em duas etapas de desenvolvimento no Kernel:
- O primeiro passo (Kernel Linux 7.3): No mês passado, um commit anterior (293f9611ae735) impediu que o balanceador de carga ociosa (NOHZ) acordasse desnecessariamente uma thread irmã para verificações de rotina. Apenas evitar essa checagem inútil saltou o desempenho do benchmark de 6,2 TFLOP/s para 9,4 TFLOP/s.
- O novo patch (Atual): A série recém-enviada aplica a mesma lógica de preservação para o agendamento de tarefas ordinárias. Com a preferência forçada pelo PE0, o desempenho subiu de 9,4 TFLOP/s para 10,1 TFLOP/s.
Além do aumento absoluto em Teraflops, a equipe relatou que as execuções se tornaram muito mais previsíveis, um fator crítico para orquestração de servidores em nuvem. O código agora está sob revisão na Linux Kernel Mailing List (LKML) e, se aprovado pelos mantenedores da arquitetura ARM64, deverá ser integrado em uma futura versão estável do kernel.
