Entendendo corrupções silenciosas de dados em uma grande população de CPUs de produção

O software supõe que um processador calcula o que suas instruções dizem. Alguns não calculam, e a falha costuma ser silenciosa: sem crash e sem exceção, apenas um checksum errado, um hash errado ou um arquivo perdido. Checksums protegem dados em repouso, mas nada equivalente avisa que uma instrução aritmética devolveu o valor errado. Os autores citam o relato da Meta de que esses casos podem levar meses de engenharia para depurar, e dizem que um caso no Alibaba Cloud levou semanas.

Este artigo do SOSP 2023 (Koblenz), da Tsinghua University, da The Ohio State University e do Alibaba Cloud, relata testes de mais de um milhão de processadores de centenas de clusters em 28 data centers de 14 países ao longo de 32 meses. Os autores dizem que é o primeiro estudo quantitativo e sistemático da corrupção silenciosa de dados (SDC) de CPU em uma frota de produção, já que os trabalhos anteriores eram teóricos, baseados em injeção de falhas ou breves. O artigo termina com o Farron, uma mitigação construída sobre os achados.

Vale separar os termos: um testcase é um dos 633 programas da toolchain do fabricante do chip, e um setting é um testcase combinado com um processador específico. Uma SDC de computação vem de unidades aritméticas, vetoriais ou de ponto flutuante defeituosas, e uma SDC de consistência vem de coerência de cache ou memória transacional defeituosas. Frequência de ocorrência é o número de erros por minuto de um setting. SDCs "apparent" (aparentes) são fáceis de disparar perto da temperatura ociosa, e as "tricky" (traiçoeiras) exigem temperatura mais alta e aparecem raramente. As taxas de falha aqui são por 10.000 CPUs (o artigo escreve ‱).

Vale conhecer antes: checksums fim a fim, ECC e erasure coding, e os campos de sinal, expoente e fração de um float IEEE-754. Dois pareamentos com artigos da biblioteca, ambos meus e não do artigo: o Orthrus é um artigo do SOSP 2025 que trata da detecção online e cita a taxa de 3,61 em 10.000 deste estudo, então é posterior a ele. As Falhas metaestáveis não são citadas aqui, mas o primeiro caso do Alibaba, resultados de checksum errados que fizeram uma aplicação repetir requisições e prejudicar o desempenho, é um pequeno exemplo de amplificação por retry.

• Uma medição na frota. Testes em quatro momentos (depois da entrega da fábrica, depois da entrega ao datacenter, depois da reinstalação e regularmente em produção), com taxas de falha por momento e por nove microarquiteturas (M1 a M9), e uma análise de se a falha atinge um core físico ou todos.
• Um olhar detalhado sobre 27 processadores defeituosos. Os autores rodaram dezenas de milhões de testes e coletaram mais de dez mil registros de SDC. Eles separam SDCs de computação das de consistência, porque as segundas só podem ser achadas por testes multithread, e usam o Pin para contar os tipos de instrução executados por testcase e restringir os suspeitos (uma instrução de arco tangente em FPU1 e FPU2, instruções de região transacional em CNST2).
• Um desafio aos modelos de falha. Os bitflips evitam os bits mais significativos dos tipos numéricos, se repetem em posições fixas dentro de um setting e às vezes invertem vários bits, ao contrário das suposições de independência e de inversão única dos modelos baseados em radiação.
• Reprodutibilidade e gatilhos. A frequência de ocorrência por setting, sua dependência da temperatura e do estresse de uso das instruções, e uma divisão das SDCs em aparentes e traiçoeiras.
• Uma avaliação das defesas. A Observação 11 sobre como o teste é desperdiçado e a Observação 12 sobre por que checksums, ECC, erasure coding, redundância e predição são enfraquecidos pelas SDCs de CPU.
• Farron. Ele opera em três estados: pré-produção, online e suspeito. Um limite de temperatura adaptativo aciona o workload backoff (reduzir a carga da aplicação) e sobe se mais da metade das leituras recentes o excede, e um limite mais baixo recebe menos tempo de teste. Os testes regulares classificam os testcases como basic, active ou suspected, favorecem os que miram recursos usados pela aplicação protegida e começam com cargas de burn-in em todos os cores para elevar a temperatura. A desativação de granularidade fina mascara um core defeituoso e aposenta o processador inteiro se mais de dois estiverem defeituosos.

O alvo é o Alibaba Cloud, com processadores de um fabricante não identificado, instalados desde 2017, cobrindo nove microarquiteturas. A ferramenta é a toolchain do fabricante: 633 testcases que imitam cargas de nuvem (uma instrução em loop, uma chamada de biblioteca ou lógica de aplicação) mais um framework que os executa. Os testes de pré-produção rodam depois da entrega da fábrica, da entrega ao datacenter e da reinstalação. Em produção, as máquinas são testadas em grupos de cerca de 2 semanas cada, e a frota inteira leva meses. Cada testcase roda em sequência com a mesma duração, e os testes regulares começaram em janeiro de 2021. Quando a causa não era clara, os processadores suspeitos foram enviados ao fabricante, que confirmou todos os relatados, e o OpenDCDiag serviu como toolchain suplementar e levou às mesmas observações.

Nos 27 processadores estudados a fundo (os demais voltaram ao fabricante), um padrão de bitflip é uma máscara de esperado XOR obtido compartilhada por mais de 5% dos registros de um setting. A temperatura veio de dados dos dispositivos de refrigeração no kernel, com a ferramenta stress do Linux pré-aquecendo cores e também rodando em outros cores para separar o calor do estresse de instruções. O Farron foi avaliado em seis dos processadores defeituosos (MIX1, SIMD1, FPU1, FPU2, CNST1, CNST2). A cobertura é o número de erros detectados sobre os erros conhecidos em uma rodada de testes, e o overhead é a duração de uma rodada sobre três meses mais o tempo de backoff sobre o tempo da simulação. A base de comparação é a prática do Alibaba: testes na pré-produção e a cada três meses, recursos iguais por testcase, aposentadoria do processador inteiro.

Estes são os resultados relatados pelos autores.

• Taxa na frota. 3,61 em cada 10.000 CPUs causam SDCs. Os testes de pré-produção acharam 3,262 (90,36% dos processadores defeituosos: 0,776 na entrega da fábrica, 0,18 na entrega ao datacenter, 2,306 depois da reinstalação) e os testes regulares 0,348. Os autores dizem que isso é mais preciso que as declarações do Google e da Meta e que as SDCs são generalizadas, não um "cisne negro".
• Chips mais novos não ajudam. Toda microarquitetura tem processadores defeituosos, com taxas de 0,082 a 9,29 em 10.000, e a taxa não cai com chips mais novos.
• Abrangência de uma falha. Em cerca de metade dos processadores defeituosos um core físico está defeituoso, na outra metade todos estão. Quando um defeito está no mesmo componente por core de todos os cores (MIX1, MIX2), os cores falham nos mesmos testcases com frequências que podem diferir em várias ordens de grandeza. Dos 27, 19 têm defeitos de computação e os demais de consistência.
• Recursos vulneráveis. Lógica aritmética, operações vetoriais, ponto flutuante, coerência de cache e memória transacional. Todo tipo de dado testado é afetado, o ponto flutuante mais que os outros. No MIX1 uma instrução defeituosa aparece em sete testcases e só dois produzem erros.
• Bitflips. 51,08% vão de zero para um (72,27% nos inteiros de 16 bits do MIX1). As inversões em ponto flutuante atingem sobretudo a fração, então as perdas são pequenas: todos os casos de 80 bits abaixo de 0,002%, 99,9% dos doubles abaixo de 0,02%, 80,25% dos singles abaixo de 5%, enquanto 40,2% das perdas em inteiros de 32 bits passam de 100%. As posições se repetem por setting, em geral um bit, com uma parcela considerável de dois ou mais.
• Reprodutibilidade. A frequência vai de 0,01 a centenas de erros por minuto e passa de um por minuto em 51,2% dos settings. Um processador defeituoso fez um serviço relatar 26 erros de dados inválidos em cerca de 4,5 horas.
• Temperatura e estresse. Em 6 de 27 processadores o log da frequência é linear na temperatura do core, com Pearson acima de 0,75. O testcase C no MIX1 falhou só acima de 59 °C (ocioso, cerca de 45 °C). Os testcases que falham usam a instrução defeituosa ordens de grandeza mais vezes, e o estresse em outros cores elevou a frequência com a temperatura quase constante. O calor explicou um core que errava só quando os outros estavam ocupados (refrigeração compartilhada), um efeito da ordem dos testes e uma atualização da toolchain cujo framework mais eficiente reduziu a frequência. A temperatura mínima de disparo e a frequência têm forte correlação negativa (Pearson de 0,8272 em módulo).
• O teste é desperdiçado. Em uma parte da frota com dezenas de milhares de CPUs, 560 dos 633 testcases não acharam nada, e alguns processadores defeituosos só erram em conflitos multithread que os testcases não cobrem.
• Defesas, por argumento. O erasure coding recupera dados perdidos mas não detecta corrupção, ECC e CRC podem abençoar um resultado já errado, o ECC padrão corrige um bit e detecta dois, a redundância é cara demais para toda aplicação, e a predição por faixa tem dificuldade com perdas pequenas de precisão.
• Farron. Uma rodada regular leva em média 1,02 hora contra 10,55 da base de comparação. A cobertura em uma rodada é maior que a da base (só em figura). O overhead total vai de 0,017% a 0,145%, contra 0,488% dos testes da base, e o workload backoff disparou 0,864 segundo por hora em média, com a temperatura abaixo de 59 °C.

Os autores deixam claro que o esforço é best effort. Eles admitem o seguinte.

• Não é um censo. A toolchain pode perder SDCs e os autores acharam algumas que ela não detecta, então falsos negativos e falsos positivos são possíveis, e distinguir uma SDC de outras causas, como erros de memória, é difícil. A toolchain não é pública, e por isso eles apontam o OpenDCDiag.
• As causas são hipóteses. Eles dizem que os cinco recursos podem ser mais vulneráveis ou apenas travar menos, e dão vários motivos possíveis para as taxas não caírem com chips novos. Os bitflips em posição fixa têm "uma explicação potencial".
• Limites da mitigação. O controle da refrigeração não custa desempenho, mas ainda não é amplamente aplicável no Alibaba Cloud, então o Farron usa workload backoff. Erros além da toolchain pedem testcases melhores, e se perdas pequenas de precisão são aceitáveis exige mais estudo.

Os pontos a seguir são uma leitura das evidências, não afirmações do artigo.

• Uma taxa de detecção de um fabricante e uma toolchain. Os 3,61 em 10.000 contam o que essa toolchain sinaliza. Compará-los com as declarações do Google e da Meta mistura ferramentas, frotas e regimes, e os denominadores da Tabela 1 não são informados: as quatro taxas somam exatamente o total, o que sugere uma única população, embora os testes regulares só alcancem processadores que passaram na pré-produção. Que todos os processadores venham de um fabricante não identificado e "representem o mainstream internacional" é afirmado.
• Escapes e início tardio não são separados. Os 0,348 dos testes regulares passaram na pré-produção, alguns por várias rodadas regulares. O artigo não diz se são falhas de início tardio ou detecções perdidas antes, e a Tabela 3 lista a idade mas nenhuma análise relaciona idade e falha. O mesmo vale para chips mais novos: microarquitetura, tempo de instalação, exposição aos testes e maturidade se misturam, e não achei no texto uma ordem de M1 a M9.
• O estudo detalhado são 27 processadores retidos, não uma amostra. Os outros foram devolvidos, então proporções como metade com um core só, 19 contra o restante e a lei de temperatura em 6 de 27 dependem do que ficou retido.
• Os bitflips são inferidos das saídas. A máscara compara a saída final de um testcase inteiro, que pode envolver várias instruções e computação posterior, então pode não mostrar onde o hardware inverteu um bit. O desafio aos modelos de inversão independente e única se apoia em poucos processadores.
• O impacto em produção é argumentado com anedotas. A Seção 2.2 traz três casos e a Observação 9 uma contagem. O estudo mede quantas CPUs falham em testes, não com que frequência aplicações viram dados corrompidos nem quanto escapou, e a frequência de erro de um testcase não é a taxa de erro de uma aplicação. Os dois primeiros casos, aliás, foram revelados por divergências de checksum, então "checksums ineficazes" se refere à corrupção anterior ao cálculo do checksum. A Observação 12 é argumentada, não testada: nenhuma defesa foi rodada contra os registros de SDC.
• A avaliação do Farron é enxuta e próxima dos próprios dados. Ela usa seis dos 27 processadores que originaram as observações, com cobertura medida contra "erros conhecidos" da mesma toolchain, e "suspected" é definido como os testcases que já falharam naquele processador. O texto não diz como as prioridades foram definidas na avaliação, então parte do ganho pode refletir conhecimento prévio. Não há processadores saudáveis, taxa de falsos positivos, frota separada para validação nem implantação, e a proteção foi checada simulando cargas por horas, com o custo relatado como tempo de backoff, não latência ou throughput.
• Pontas soltas nos números. Não consegui ligar os 0,864 s por hora (cerca de 0,024%) à Tabela 4, cujo overhead de controle vai de 0 a 0,049% (até cerca de 1,8 s por hora), e o limite de 59 °C coincide com o limiar que o artigo relata para um setting (testcase C no MIX1), enquanto o texto não diz quais processadores a simulação usou. A desativação fina (mascarar um core, aposentar acima de dois) e o pool confiável não são avaliados, embora metade das falhas afete todos os cores.

• Melhor geração de testcases para conflitos multithread, que os autores esperam da academia e da indústria e para a qual citam o SiliFuzz sem experimentá-lo. A receita lembra o Csmith para compiladores (programas aleatórios mais uma verificação cruzada), pareamento meu, não do artigo.
• Modelos de falha e codificações que sigam os padrões de bitflip, e o impacto em aplicações de erros pequenos em ponto flutuante em áreas como finanças ou veículos autônomos.
• Controle dos dispositivos de refrigeração e uso contínuo dos cores não afetados de um processador defeituoso, que os autores consideram digno de investigação, validados em uma frota separada e com outros fabricantes.
• Tolerância online voltada aos poucos recursos vulneráveis, que os autores colocam como pergunta. O Orthrus é uma resposta posterior, reexecutando operadores do caminho de dados em outro core.