Os engenheiros da Red Hat estão trabalhando para resolver a Especulação Restrita de Filial Indireta (IBRS), que é muito cara para mitigar o Spectre V2 e o Retbleed em processadores Intel Xeon Scalable mais antigos. Então, a Red Hat tenta resolver mitigação do IBRS que afeta desempenho.
Um novo patch foi lançado para desabilitar o IBRS quando ocioso e está funcionando bem pelo menos para o Red Hat Enterprise Linux 9, embora ainda não esteja claro se ele será aceito no kernel upstream.
O patch de Waiman Long da Red Hat explica as dores que eles ainda estão enfrentando em relação ao Intel IBRS para lidar com Specter e Retbleed:
Para processadores Intel que precisam ativar o IBRS para proteção contra Spectre v2 e Retbleed, o bit IBRS no SPEC_CTRL MSR afeta o desempenho de todo o núcleo, mesmo que apenas um thread o esteja ativando ao executar no kernel. Para aplicativos com uso intenso de espaço do usuário, o impacto no desempenho de ocasionalmente ativar o IBRS durante syscalls não deve ser significativo. Infelizmente, esse não é o caso quando a thread irmã está ociosa no kernel. Nesse caso, o impacto no desempenho pode ser significativo.Quando o DPDK está sendo executado em um thread isolado da CPU processando pacotes de rede no espaço do usuário enquanto seu thread irmão está ocioso.
O desempenho do encadeamento DPDK ocupado com IBRS ativado e desativado no encadeamento inativo irmão é:IBRS on IBRS off——- ——–pacotes/segundo: 7,8M 10,4Mmédia tsc ciclos/pacote: 282,26 209,86Esta é uma degradação de desempenho de 25%.
O sistema de teste é uma CPU Intel Xeon 4114 @ 2,20 GHz.Esta série de patches desativa o IBRS quando está em vários modos ociosos para eliminar o impacto no desempenho do encadeamento ocioso em seu encadeamento irmão ocupado.
Red Hat tenta resolver mitigação do IBRS que afeta desempenho
Ouch, um sucesso de 25% no Xeon Scalable Skylake para o Data Plane Development Kit (DPDK) de código aberto.
Existe este thread do kernel onde o patch para desabilitar o IBRS quando ocioso está sendo lançado. O proeminente engenheiro da Intel Linux, Peter Zijlstra, sugeriu outro patch que atualmente não é portado para RHEL9. Além disso, a possibilidade de usar Call Depth Stuff/Tracking em vez de IBRS.
Em meus testes, o Call Depth Tracking encontrado no Linux 6.2+ da linha principal está realmente oferecendo para ajudar a recuperar algum desempenho perdido nas CPUs da era Intel Skylakeque de outra forma dependem do IBRS.
Portanto, veremos para onde vai a atividade upstream do kernel ou se a Red Hat acaba carregando apenas esse patch como parte de seu kernel RHEL9 por enquanto até o back-porting de quaisquer novas opções. De qualquer forma, este último tópico da lista de discussão do kernel continua a mostrar as dores de mitigação ainda experimentadas pelos usuários corporativos do Linux em meados de 2023 em plataformas mais antigas.