Confira !!
Ontem, a Intel publicou a errata do código condicional de salto (JCC). Este é um bug que envolve o ICache Decoded da CPU, no Skylake, e as CPUs derivadas, onde um comportamento imprevisível pode ocorrer quando as instruções de salto cruzam as linhas de cache. Infelizmente, resolver esse erro no software tem uma penalidade de desempenho, mas os engenheiros da Intel estão trabalhando para compensar isso através de uma atualização da cadeia de ferramentas. Aqui estão os benchmarks exclusivos hoje em dia do impacto no desempenho da errata JCC, bem como ao tentar recuperar esse desempenho através do GNU Assembler atualizado.
A Errata do Código Condicional do Salto
O problema em questão resume-se às instruções que cruzam as linhas de cache, onde no Skylake por Cascadelake existe o potencial de "comportamento imprevisível" relacionado ao ICache Decodificado / Buffer de Transmissão Decodificado.
A atualização do microcódigo impede que as instruções de salto sejam armazenadas em cache no Icache decodificado quando essas instruções ultrapassam um limite de 32 bytes ou quando terminam em um limite de 32 bytes. Devido a essa alteração, haverá mais erros do ICache decodificado e retornará ao pipeline de decodificação herdado - resultando em uma nova penalidade de desempenho. O ICache Decodificado / Buffer de Transmissão Decodificado existe desde Sandy Bridge, mas apenas Skylake e mais recentes são afetados por esta errata. O Cascade Lake é afetado por esta errata, mas o Ice Lake e as iterações futuras não são afetadas. O aviso de errata lista oficialmente os lagos Amber Lake, Cascade Lake, Coffee Lake, Comet Lake, Kaby Lake, Skylake e Whisky Lake como gerações afetadas pelo bug do JCC.
Embora essa mitigação de microcódigo produza um impacto no desempenho de muitas cargas de trabalho, a Intel está tentando compensar esse impacto no desempenho por meio de uma atualização da cadeia de ferramentas do compilador no assembler sobre o comportamento das instruções de salto.
A Intel teve a gentileza de nos informar antecipadamente sobre a questão JCC, a fim de realizar nossos próprios testes de desempenho independentes, tanto no impacto do microcódigo quanto no - pelo menos parcialmente - desempenho recuperado ao usar os bits atualizados da cadeia de ferramentas do compilador. Essa errata não está sendo descrita como um problema de segurança, mas apenas como um "comportamento imprevisível" potencialmente quando instruções de salto cruzam as linhas de cache.
Orientação de desempenho da Intel
As orientações oficiais da Intel divulgadas ontem afirmam que seus efeitos de desempenho observados nesta atualização de microcódigo estão na faixa de 0 a 4%, mas com alguns "valores discrepantes superiores à faixa de 0 a 4%".
Diferentemente das vulnerabilidades de execução especulativa Spectre / Meltdown / L1TF / MDS, em que as atenuações afetam principalmente as cargas de trabalho que interagem com o kernel e alternam entre o espaço do usuário / kernel, a atualização do microcódigo da errata do JCC pode afetar apenas as cargas de trabalho do espaço do usuário, dependendo de muitos saltos abrangendo limites de 32 bytes. Portanto, embora o impacto no desempenho possa estar apenas nos dígitos de um dígito, mais cargas de trabalho são afetadas do que vimos em algumas das vulnerabilidades de segurança de execução especulativa recentes.
Ajudando a reduzir o impacto no desempenho
Para ajudar a compensar o impacto do microcódigo atualizado, os engenheiros da Intel têm trabalhado nas atualizações da cadeia de ferramentas para tentar garantir que as instruções de salto não ultrapassem os limites de 32 bytes ou terminem em um limite de 32 bytes. A Intel possui patches no GNU Assembler por poder alinhar saltos dentro de um limite de 32 bytes e vários sinalizadores para alternar o comportamento. Obviamente, esses patches ainda precisam avançar até as versões lançadas do GNU Assembler e de outros montadores e daí serem escolhidos pelos vários sistemas operacionais, etc.
Dado o modo como geralmente vemos essas atualizações ocorrerem, sem as distribuições de lançamento contínuo, provavelmente não será até a próxima rodada de lançamentos de distribuição do Linux antes que o software seja construído com o assembler corrigido. Mesmo que um assembler atualizado o faça como uma atualização estável de versão para distribuições sem lançamento contínuo, ainda é o problema de todo o software que precisa ser recompilado com esta solução alternativa para evitar os saltos nos limites de 32 bytes. Portanto, pelo menos existe a capacidade de recuperar parcialmente completamente a queda de desempenho do microcódigo, mas provavelmente levará algum tempo até que os usuários em geral tenham o assembler atualizado em seus sistemas, a menos que proativamente o faça. Por outro lado, distribuições como o Ubuntu tendem a enviar atualizações de microcódigo mais ativamente como atualizações de versão estáveis do que as peças-chave de sua cadeia de ferramentas, por isso '
Há também a questão de quando os fornecedores de software proprietário também enviam software reconstruído com a cadeia de ferramentas atualizada e casos como jogos ou outro software voltado para o desempenho que talvez nunca veja essas reconstruções.
Fonte
Até a próxima !!
Nenhum comentário:
Postar um comentário