Die auf der Linux Plumbers Conference 2026 vorgestellten ersten Messungen zur Auto-Vektorisierung des Linux-Kernels für RISC-V fallen je nach Arbeitslast und Zielsystem unterschiedlich aus: Bei der LZ4-Kompression reichen sie von +15,1 % auf ASC-X bis −7,5 % auf K3. Die Folien der Konferenz schlüsseln die Ergebnisse nach Vorgang und Zielsystem auf.

Auto-Vektorisierung bedeutet, dass der Compiler geeigneten Code so übersetzt, dass er Vektorbefehle nutzt. Die offizielle Beitragsbeschreibung ordnet die Untersuchung als erste Experimente ein. Die Linux Plumbers Conference fand vom 5. bis 7. Oktober 2026 statt.

Die Ergebnisse unterscheiden sich nach Arbeitslast und Zielsystem

Alle folgenden Prozentwerte sind in den Folien als Veränderungen gegenüber mtune angegeben. Bei LZ4 stehen Kompression und Dekompression getrennt; bei Btrfs sind die Vorgänge Anlegen und Löschen. Für Nginx beziehen sich die Werte auf Auslieferungsgrößen von 80 Byte bis 32 KB.

Arbeitslast und VorgangZielsystemErgebnis gegenüber mtuneMesskontext
LZ4 (zram), KompressionASC-X+15,1 %Kompression
LZ4 (zram), DekompressionASC-X+1,0 %Dekompression
LZ4 (zram), KompressionK3−7,5 %Kompression
LZ4 (zram), DekompressionK3+9,4 %Dekompression
Btrfs (fsmeta), AnlegenASC-X+5,2 %Metadatenvorgang: Anlegen
Btrfs (fsmeta), LöschenASC-X+8,4 %Metadatenvorgang: Löschen
Btrfs (fsmeta), AnlegenK3+6,9 %Metadatenvorgang: Anlegen
Btrfs (fsmeta), LöschenK3+3,7 %Metadatenvorgang: Löschen
XFS (fsmeta)ASC-X+2,5 % und +5,0 %Zwei Werte; die Vorgänge sind nicht einzeln bezeichnet
XFS (fsmeta)K3Nicht signifikantErgebnis der Folien
NginxASC-S0,9 bis +2,2 %Auslieferungsgrößen von 80 Byte bis 32 KB
NginxK30,3 bis +1,9 %Auslieferungsgrößen von 80 Byte bis 32 KB

Der Vergleich zeigt, warum ein Spitzenwert nicht für jede Aufgabe gilt: Auf ASC-X steht dem Plus von 15,1 Prozent bei der LZ4-Kompression ein Plus von 1,0 Prozent bei der Dekompression gegenüber. Auf K3 fällt die Kompression um 7,5 Prozent, während die Dekompression um 9,4 Prozent zulegt. Auch die Btrfs-Werte unterscheiden sich je nach Vorgang und Zielsystem; für XFS ist das K3-Ergebnis als nicht signifikant gekennzeichnet.

Über die Systembenchmarks auf K3 hinweg lag der geometrische Mittelwert bei +0,1 Prozent. Zu den negativen Einzelwerten gehörten neben der LZ4-Kompression auch Hackbench-Tests für Prozesse und Threads mit −2,51 beziehungsweise −4,06 Prozent. Der Mittelwert und die Einzelmessungen beschreiben damit unterschiedliche Ausschnitte der Ergebnisse.

Userspace-Steuerung und Kernel-Nutzung

Die dokumentierten Linux-Schnittstellen für RISC-V Vector betreffen den Userspace: PR_RISCV_V_SET_CONTROL und PR_RISCV_V_GET_CONTROL steuern die Vector-Verfügbarkeit für den aufrufenden Thread; /proc/sys/abi/riscv_v_default_allow legt den Standard für neue Userspace-Prozesse fest. Die Linux-Kerneldokumentation beschreibt diese Schnittstellen für Programme und Prozesse.

Die Kernel-Nutzung im Konferenzversuch folgt einem eigenen Modell. In dem beschriebenen Kernel-Kontext ist Vector standardmäßig deaktiviert; die Folien zeigen eine ausdrückliche Nutzung über kernel_vector_begin() und kernel_vector_end() sowie das Sichern und Wiederherstellen des Zustands. Die Schnittstellen für Userspace-Prozesse schalten diese Kernel-Verwendung nicht ein.

Kontextverwaltung und Compilerabstimmung

Vektorregisterzustand muss beim Wechsel zwischen Aufgaben verwaltet werden. Die Folien beziffern das Sichern der Register v0–v31 mit 512 B bei VLEN 128 und 4 KiB bei VLEN 1024. Die Beitragsbeschreibung nennt außerdem die Verwaltung eines vektorlängenunabhängigen Kontexts und den Wartungsaufwand automatisch vektorisierter Codeabschnitte als Herausforderungen.

Die Quellcode-Beispiele der Präsentation führen GCC 16.1 und die Abstimmungsoption -mtune=tt-ascalon-d8 an. Zusammen mit den unterschiedlichen Ergebnissen je Zielsystem macht das deutlich, wie eng die Messwerte an Arbeitslast und Compilerabstimmung gebunden sind.