A vetorização do kernel Linux em RISC-V varia por carga

As medições iniciais de autovetorização do kernel Linux para RISC-V apresentadas na Linux Plumbers Conference 2026 variam conforme a carga, a operação e o alvo de hardware: na compressão LZ4, por exemplo, o resultado vai de +15,1% no ASC-X a -7,5% no K3, em relação ao mtune. O encontro ocorreu de 5 a 7 de outubro; os slides da apresentação detalham os resultados, e a página da conferência descreve o trabalho como uma investigação inicial sobre benefícios potenciais, gerenciamento de contexto e manutenção.

Autovetorização é o processo pelo qual o compilador transforma trechos de código para usar instruções que operam sobre vários dados de uma vez. Nos testes apresentados, os percentuais são resultados em relação ao mtune, e não uma medida única de aceleração do kernel.

Resultados por carga, operação e alvo

Os slides apresentam resultados diferentes para compressão e descompressão do LZ4, além de testes de metadados de sistemas de arquivos e de atendimento do Nginx. Os valores abaixo são os ganhos ou a regressão reportados em relação ao mtune.

O contraste no LZ4 é direto: a compressão melhorou no ASC-X e regrediu no K3, enquanto a descompressão teve ganhos nos dois alvos. No Btrfs, criação e remoção também apresentaram percentuais diferentes. Por isso, um resultado de pico não descreve o comportamento de todas as operações nem de todos os alvos.

O pico não representa o resultado do sistema

No conjunto de benchmarks de sistema para K3, os slides reportam ganho de média geométrica de 0,1%. Entre os resultados negativos do Hackbench estão -2,51% nos testes de processos e -4,06% nos de threads. Assim, o ganho de +15,1% na compressão LZ4 no ASC-X é um resultado específico daquela carga e daquele alvo, não um aumento geral de desempenho do sistema.

Os slides também mostram exemplos de código com GCC 16.1 e a opção -mtune=tt-ascalon-d8. A apresentação traz à parte resultados de builds não portáveis ajustados para alvos específicos; esses números usam uma comparação diferente da tabela acima e não devem ser misturados aos ganhos em relação ao mtune.

Controles Vector de usuário e uso no kernel

Os controles Vector documentados pelo Linux se aplicam ao espaço de usuário: PR_RISCV_V_SET_CONTROL e PR_RISCV_V_GET_CONTROL controlam a disponibilidade para a thread que faz a chamada, e /proc/sys/abi/riscv_v_default_allow define o padrão para novos processos. Esses mecanismos não ativam a autovetorização do kernel. A documentação oficial do Linux também informa que chamadas de sistema podem sobrescrever os registradores Vector conforme a convenção documentada.

O experimento no kernel exige gerenciamento próprio do estado Vector. Os slides descrevem o uso explícito de kernel_vector_begin() e kernel_vector_end(), além de salvar e restaurar esse estado. O exemplo apresentado restringe esse uso em contextos de interrupção não mascarável (NMI) e de interrupção de hardware de alta prioridade (hard IRQ).

Estado dos registradores e manutenção

Salvar o estado Vector consome tempo e memória. Para os registradores v0 a v31, a tabela da apresentação indica 512 B com VLEN 128 e 4 KiB com VLEN 1024. Esses valores se referem ao estado dos registradores. A descrição da contribuição também aponta o gerenciamento de contexto independente do comprimento do vetor (VLA) e a manutenção do código autovetorizado como desafios do trabalho.