Tijdens Linux Plumbers Conference 2026, gehouden van 5 tot en met 7 oktober, lieten eerste experimenten met auto-vectorisatie van de RISC-V-kernel uiteenlopende resultaten zien. De winst hing af van de werklast, de bewerking en het hardwaredoel: LZ4-compressie boekte op ASC-X 15,1% winst, maar liep op K3 7,5% terug. De conferentiepagina omschrijft het werk als verkennend; de slides geven de uitsplitsing per test.
Resultaten verschillen per werklast en hardwaredoel
Auto-vectorisatie laat een compiler geschikte code omzetten in vectorinstructies. De prestaties hieronder zijn percentages ten opzichte van mtune; ze zijn afkomstig uit de experimenten in de conferentieslides. De afkortingen ASC-X, ASC-S en K3 zijn de hardwaredoelen zoals die daarin staan.
| Werklast en bewerking | Hardwaredoel | Resultaat ten opzichte van mtune | Meetcontext |
| LZ4 (zram), comprimeren | ASC-X | +15,1% | Compressie |
| LZ4 (zram), decomprimeren | ASC-X | +1,0% | Decompressie |
| LZ4 (zram), comprimeren | K3 | -7,5% | Compressie |
| LZ4 (zram), decomprimeren | K3 | +9,4% | Decompressie |
| Btrfs (fsmeta), aanmaken | ASC-X | +5,2% | Metadata aanmaken |
| Btrfs (fsmeta), verwijderen | ASC-X | +8,4% | Metadata verwijderen |
| Btrfs (fsmeta), aanmaken | K3 | +6,9% | Metadata aanmaken |
| Btrfs (fsmeta), verwijderen | K3 | +3,7% | Metadata verwijderen |
| XFS (fsmeta) | ASC-X | +2,5% en 5,0% | Twee resultaten; de bewerkingen zijn niet afzonderlijk benoemd |
| XFS (fsmeta) | K3 | Niet significant | XFS-metadatatest |
| Nginx | ASC-S | +0,9% tot +2,2% | Servergroottes van 80 B tot 32 KB |
| Nginx | K3 | +0,3% tot +1,9% | Servergroottes van 80 B tot 32 KB |
De uitersten bij LZ4 laten zien waarom één piekcijfer niet volstaat: compressie en decompressie zijn verschillende tests, en hetzelfde type werk kan per doel anders uitpakken. Ook bij Btrfs verschilt de uitkomst tussen aanmaken en verwijderen. Voor K3 noemt de XFS-test geen significant resultaat. De slides rapporteren deze waarden als winst ten opzichte van mtune.
Dat verschil is ook zichtbaar in het totaal: over de systeembenchmarks op K3 rapporteert de presentatie een geometrisch gemiddelde van +0,1%. Daar staan negatieve uitschieters tegenover, waaronder -7,5% voor LZ4-compressie en -2,51% en -4,06% voor respectievelijk de proces- en threadtests van hackbench. Een afzonderlijke slide behandelt een niet-portabele build die sterker op de doelprocessor is afgestemd. Die rapporteert voor K3 een geometrisch gemiddelde van +4,98% over 24 systeembenchmarks en +34,8% voor zram-LZ4. Dat zijn andere vergelijkingsvoorwaarden dan de resultaten in de tabel.
Userspace-instellingen regelen het kernelgebruik niet
De Linux-instellingen voor de RISC-V Vector-extensie gelden voor gebruikersprogramma’s. PR_RISCV_V_SET_CONTROL en PR_RISCV_V_GET_CONTROL regelen de Vector-toegang van een userspace-thread; /proc/sys/abi/riscv_v_default_allow bepaalt de standaard voor nieuwe userspace-processen. De Linux-documentatie beschrijft deze interfaces als userspace-regelingen.
De kernelproef vraagt om afzonderlijk beheer van de vectorstatus. In de slides staan de functies kernel_vector_begin() en kernel_vector_end() voor het afbakenen van vectorwerk en het opslaan en herstellen van die status. Dat is een ander mechanisme dan de prctl()- en sysctl-instellingen voor gebruikersprocessen. In het getoonde voorbeeld zijn hard-IRQ- en NMI-contexten uitgesloten.
Contextbeheer en afstemming op een processor
Vectorlengte-onafhankelijkheid — code kunnen laten werken met verschillende vectorlengtes — maakt het beheer van de vectorstatus een van de aandachtspunten. Het opslaan van de registers v0–v31 neemt volgens de slides 512 B in beslag bij VLEN 128 en 4 KiB bij VLEN 1024. Die cijfers gaan over de registerstatus die wordt opgeslagen; ze beschrijven niet het totale geheugengebruik van de kernel.
De presentatie noemt GCC 16.1 en -mtune=tt-ascalon-d8 in voorbeelden van auto-vectoriseerbare kernelcode. Dat is een concreet compiler- en afstemmingsvoorbeeld, geen instelling die voor alle benchmarkresultaten is vastgesteld. De LPC-beschrijving noemt zowel het beheer van vectorcontexten als het onderhoud van de auto-vectoriseerde code als uitdagingen.
