Auto-vectorisation du noyau Linux sur RISC-V : des résultats contrastés

Lors de la Linux Plumbers Conference 2026, tenue du 5 au 7 octobre, une présentation a exposé des expériences initiales d’auto-vectorisation du noyau Linux pour RISC-V. Les résultats varient selon la charge et la cible matérielle : sur LZ4, la compression progresse de 15,1 % sur ASC-X, mais recule de 7,5 % sur K3. La description officielle de la contribution présente aussi la gestion du contexte vectoriel et la maintenance du code comme des défis.

Ce que mesure l’expérience

L’auto-vectorisation consiste à laisser le compilateur repérer dans le code des opérations qu’il peut traduire en instructions vectorielles, capables de traiter plusieurs données à la fois. Dans le contexte étudié, l’extension Vector est désactivée par défaut pour le noyau ; son utilisation demande un appel explicite à une API du noyau.

Les valeurs ci-dessous sont des variations par rapport à mtune. Elles distinguent les opérations et les cibles indiquées dans les diapositives de la présentation : un pourcentage élevé sur une charge ne décrit donc pas à lui seul le comportement des autres.

L’écart entre les deux résultats LZ4 sur K3 est parlant : la décompression affiche +9,4 %, tandis que la compression recule de 7,5 %. Btrfs présente également des résultats différents selon qu’il s’agit de créer ou de supprimer des métadonnées. Pour XFS, la mesure sur K3 est indiquée comme non significative.

Le résultat agrégé est bien plus modeste

Sur K3, la moyenne géométrique des tests système indiquée dans la présentation est de +0,1 %. Les résultats comprennent aussi des reculs de 2,51 % et 4,06 % pour les tests hackbench portant respectivement sur les processus et les threads, en plus des -7,5 % en compression LZ4. Le meilleur résultat d’une charge ne résume donc pas celui de l’ensemble des tests.

Une autre série, distincte des variations par rapport à mtune, porte sur des compilations non portables mieux adaptées à la cible. Elle rapporte pour K3 une moyenne géométrique de +4,98 % sur 24 tests système et +34,8 % sur zram-LZ4. Pour ASC-X, elle indique +90,6 % sur zram-LZ4, +35,4 % sur zram-zstd et +7,4 % et +7,2 % pour les opérations de création et de suppression Btrfs. Ces chiffres reposent sur une autre comparaison et ne se mélangent pas à ceux du tableau.

Les exemples de code source des diapositives citent GCC 16.1 et l’option -mtune=tt-ascalon-d8. Un réglage plus ciblé peut donc modifier les résultats, mais les compilations mieux adaptées présentées séparément sont explicitement non portables.

Vector dans l’espace utilisateur et dans le noyau

Les commandes documentées par Linux ne déclenchent pas l’auto-vectorisation du noyau. PR_RISCV_V_SET_CONTROL et PR_RISCV_V_GET_CONTROL gèrent l’accès à Vector pour le thread appelant dans l’espace utilisateur ; /proc/sys/abi/riscv_v_default_allow définit le réglage par défaut des nouveaux processus utilisateur. La documentation Linux sur Vector pour RISC-V précise aussi que les registres vectoriels sont écrasés par les appels système.

L’expérience dans le noyau relève d’une autre gestion : les diapositives décrivent notamment les appels kernel_vector_begin() et kernel_vector_end() pour encadrer l’usage des instructions et la sauvegarde-restauration de l’état vectoriel. L’exemple présenté impose également des restrictions dans les contextes d’interruption matérielle non masquable (NMI) et d’interruption matérielle (hard IRQ).

La taille de l’état à sauvegarder dépend de la longueur vectorielle (VLEN) : pour les registres v0 à v31, la présentation indique 512 octets à VLEN 128 et 4 Kio à VLEN 1024. La gestion du contexte et l’entretien du code vectorisé restent ainsi au cœur des défis exposés à la conférence.