O TLB bug e o problema do Cool’n’Quiet

Um fator que atrapalhou as vendas do Phenom foi o infame TLB bug que atingiu as primeiras versões do chip. Devido às inúmeras operações lógicas de movimentação de dados e checagem de coerência, sem falar nas próprias instruções, bugs em processadores são uma ocorrência relativamente comum. Na década de 1990, por exemplo, a Intel sofreu com um bug no coprocessador aritmético das primeiras versões do Pentium, que levou a um massivo recall dos chips. No caso do Phenom as consequências foram menos dramáticas, mas o impacto sobre as vendas acabou sendo grande, já que ninguém quer comprar um chip com defeito.

O TLB (Translation Lookaside Buffer) é uma espécie de índice de endereços usado em todos os processadores atuais. Ele tem a função de cachear endereços (apenas os endereços, não os dados propriamente ditos) de dados disponíveis nos caches e na memória, permitindo que eles sejam localizados rapidamente, sem necessidade de fazer o processo de busca sequencial nas páginas de endereços.

Conforme os dados são modificados e copiados de um lugar para o outro, as entradas no TLB precisam ser atualizadas de acordo, um processo que parece simples na teoria, mas que na prática exige algoritmos bastante sofisticados. No caso do Phenom a tarefa é especialmente complexa, já que além dos caches L1 e L2 em cada núcleo, temos também um cache L3 que é compartilhado por todos. Devido ao uso do sistema de cache exclusivo adotado pela AMD, os caches L1 e L2 dos cores armazenam dados diferentes dos armazenados no cache L3, o que torna necessário sincronizar cuidadosamente todas as atualizações.

O bug surge em situações onde dados nos caches são modificados enquanto o controlador do TLB está modificando as entradas para refletir uma alteração anterior. Na maioria dos casos, os erros são detectados pelo circuito de controle dos caches, sem causar maiores danos, mas em determinadas situações ele pode levar à corrupção de dados, causando um hard-lock do processador.

O bug no TLB é uma ocorrência relativamente rara, mas pode se manifestar em situações de alta utilização do chip, especialmente ao usar o Xen com um grande número de máquinas virtuais (um cenário muito comum em servidores), disparando a proteção contra corrupção de dados do chip e travando todo o sistema. Outro fator é que quanto mais alta a frequência de operação do chip, mais propenso ele se torna a exibir o problema, o que obrigou a AMD a limitar a frequência de operação dos chips (a série inicial parou nos 2.3 GHz) e atrapalhou a vida de quem fazia overclock.

A primeira correção para o problema veio na forma de uma correção de BIOS, que passou a ser usada por todos os fabricantes. Ela faz com que seja mostrada a opção “Patch AMD TLB Erratum” na seção “Advanced BIOS Features”, que permite ativar ou desativar a correção. Ela pode ser ativada ou desativada também através do AMD Overdrive, no Windows.

A correção simplesmente desativa parte do circuito de TLB, prevenindo o problema, mas em troca reduzindo bastante a eficiência do mecanismo. Isso causa um aumento considerável na latência de acesso à memória, reduzindo substancialmente o desempenho do processador. Na maioria das aplicações a queda é de 6 a 10% (o que já é substancial), mas em algumas tarefas específicas, como no caso da compressão de arquivos usando o WinRAR a redução pode chegar a 70%, o que é inaceitável. Você pode ver alguns números no: http://techreport.com/articles.x/13741/3

Este é um dos casos em que o remédio acaba saindo pior do que a doença, fazendo com que muitos prefiram manter a opção desativada, arcando com a possibilidade de encontrar travamentos esporádicos em troca de um desempenho mais previsível.

A solução definitiva veio com o Phenom B3, que chegou ao mercado em março de 2008. Você pode verificar rapidamente se tem um deles em mãos usando o CPU-Z; basta checar o campo “Revision”:

Naturalmente, o fix se estende também a todos os modelos posteriores, incluindo o Phenom II e o Athlon II. Como o erro foi descoberto pouco depois do lançamento do processador, o número de unidades com o defeito que realmente chegaram ao mercado foi relativamente pequeno, mas foi suficiente para comprometer todo um trimestre de vendas da AMD.

Outro problema que afetou negativamente o desempenho do Phenom foi a inclusão de um sistema de gerenciamento independente da frequência dos cores no Cool’n’Quiet. No novo sistema, a frequência dos núcleos pode ser gerenciada independentemente, com a frequência dos núcleos ociosos sendo reduzida pela metade, o que faz bastante sentido em aplicativos sem otimização para vários núcleos, permitindo que um deles opere à frequência máxima e os demais entrem em estado de baixo consumo.

O Phenom foi o primeiro processador quad-core a oferecer essa função. Entretanto, o sistema acabou esbarrando na maneira como o Windows Vista gerencia os threads ao rodar sobre um processador multicore.

Em vez de simplesmente manter os threads rodando sobre o núcleo sobre o qual eles são iniciados, o Vista utiliza um sistema de balanceamento de carga que move os threads para os núcleos ociosos com o objetivo de distribuir melhor o trabalho e assim obter um melhor desempenho em processadores multicore.

O sistema funciona bem caso os núcleos operem à mesma frequência (como no Core 2 Quad), mas ele acaba sabotando o sistema de gerenciamento do Phenom. Quando o thread é aberto, ele começa rodando sobre o primeiro núcleo, que está operando à frequência máxima. Pouco depois o Vista o move para o segundo núcleo (que está trabalhando à metade da frequência), o que derruba o desempenho momentaneamente, até que o Cool’n’Quiet perceba a mudança e coloque-o para trabalhar na frequência máxima. Pouco depois o thread é novamente transferido para o terceiro, para o quarto e depois de volta para o primeiro, repetindo a perda em cada mudança.

Essa pendenga é na verdade um problema com o Vista e não com o Cool’n’Quiet, mas o resultado é que ela acaba causando uma perda de desempenho de até 10% em muitos aplicativos, o que faz com que muitos prefiram simplesmente desativar o Cool’n’Quiet no Setup (ou usar o perfil “Máximo desempenho” no perfil de gerenciamento de energia do Windows, que possui um efeito similar). Isso soluciona o problema da perda de desempenho, mas em compensação aumenta de forma substancial o consumo elétrico.

Para evitar repetir a queda de braço, a AMD adotou um sistema mais conservativo no Phenom II, desativando o gerenciamento independente, mas em troca adicionando mais P-States, ou seja, mais estágios intermediários de frequência. Enquanto o Phenom possui apenas dois estágios (50 ou 100% do clock), o Phenom II possui quatro estágios.

Um Phenom II X4 940, por exemplo, pode operar a 3.0 GHz, 2.3 GHz, 1.8 GHz ou 800 MHz, de acordo com o nível de carregamento. Todos os cores operam à mesma frequência, o que faz com que o sistema não seja tão eficiente, mas em compensação, não existem mais problemas com o gerenciamento do Vista e você pode manter o Cool’n’Quiet ativado sem dores de cabeça.

A Intel chegou a uma solução mais elegante no Core i7, onde os núcleos ociosos são desativados completamente, como parte do Turbo Mode. Isso evita o problema da transferência dos threads, já que o sistema passa a utilizar apenas o núcleo que está ativo, deixando que o PCU (o controlador incluído no processador) decida quando o nível de carga é suficiente para ativar os demais.

Uma curiosidade é que o problema com o Cool’n’Quiet no Phenom afeta apenas os usuários de placas AM2+, já que as placas AM2 não suportam o gerenciamento independente. Isso resultava em situações estranhas, onde máquinas “antigas”, com placas AM2, apresentavam um desempenho superior ao de máquinas mais novas, com placas AM2+, utilizando os mesmos processadores.

Sobre o Autor

Redes Sociais:

Deixe seu comentário

X