Le prove iniziali di auto-vettorizzazione del kernel Linux per RISC-V hanno dato risultati diversi a seconda del carico, dell’operazione e dell’obiettivo hardware: la compressione LZ4 è migliorata del 15,1% su ASC-X, ma è peggiorata del 7,5% su K3. Le misure sono state presentate alla Linux Plumbers Conference 2026, svoltasi a Praga dal 5 al 7 ottobre; le slide riportano i guadagni rispetto a mtune e includono anche test su Btrfs, XFS e Nginx (descrizione ufficiale della sessione; slide della presentazione).
Per auto-vettorizzazione si intende la generazione automatica, da parte del compilatore, di istruzioni che elaborano più dati in parallelo. Nel contesto descritto dalle slide, Vector è disattivato per impostazione predefinita nel kernel; il suo uso richiede una gestione esplicita del contesto.
I risultati cambiano con il carico e l’obiettivo
Le percentuali della tabella sono guadagni rispetto a mtune. Per LZ4 zram, compressione e decompressione sono riportate in quest’ordine; per Btrfs fsmeta, le operazioni sono creazione e rimozione.
| Carico e operazione | Obiettivo hardware | Risultato rispetto a mtune | Condizioni |
| LZ4 zram, compressione | ASC-X | +15,1% | — |
| LZ4 zram, decompressione | ASC-X | +1,0% | — |
| LZ4 zram, compressione | K3 | −7,5% | — |
| LZ4 zram, decompressione | K3 | +9,4% | — |
| Btrfs fsmeta, creazione | ASC-X | +5,2% | — |
| Btrfs fsmeta, rimozione | ASC-X | +8,4% | — |
| Btrfs fsmeta, creazione | K3 | +6,9% | — |
| Btrfs fsmeta, rimozione | K3 | +3,7% | — |
| Nginx | ASC-S | da +0,9% a +2,2% | Dimensioni servite: da 80 B a 32 KB |
| Nginx | K3 | da +0,3% a +1,9% | Dimensioni servite: da 80 B a 32 KB |
Per XFS fsmeta, le slide riportano su ASC-X +2,5% e +5,0%, senza associare i due valori a singole operazioni; il risultato su K3 è indicato come non significativo. Il dato di LZ4 su K3 mostra perché il valore migliore non basta a descrivere tutte le prove: anche tra compressione e decompressione dello stesso carico, l’esito cambia.
Il picco di un test non è la media del sistema
Per i benchmark di sistema su K3, le slide indicano una media geometrica del +0,1%. Tra gli esiti negativi figurano la compressione LZ4 (−7,5%) e i test hackbench su processi e thread (−2,51% e −4,06%). Il risultato di un singolo carico, quindi, non descrive da solo l’andamento dell’insieme.
Una diapositiva distinta presenta risultati per una build non portabile e ottimizzata più strettamente per il processore: per K3 indica una media geometrica del +4,98% su 24 benchmark di sistema. Per ASC-X riporta +90,6% su zram-LZ4, +35,4% su zram-zstd e +7,4% e +7,2% per creazione e rimozione in Btrfs. Sono risultati di un confronto separato da quello rispetto a mtune nella tabella: accostarli come se avessero la stessa base altererebbe il significato delle percentuali.
I controlli Vector di Linux riguardano lo spazio utente
Le interfacce Linux PR_RISCV_V_SET_CONTROL e PR_RISCV_V_GET_CONTROL regolano l’uso di Vector per il thread nello spazio utente; /proc/sys/abi/riscv_v_default_allow definisce l’impostazione predefinita per i nuovi processi utente. La documentazione ufficiale del kernel Linux specifica inoltre che le chiamate di sistema possono sovrascrivere i registri Vector secondo la convenzione documentata.
Questi controlli gestiscono l’accesso di thread e processi utente. L’esperimento sul kernel richiede invece meccanismi separati per iniziare l’uso dei registri e salvare e ripristinare il contesto, come kernel_vector_begin() e kernel_vector_end() nelle slide.
Stato dei registri e gestione del contesto
Il salvataggio dei registri Vector v0–v31 occupa 512 B con VLEN 128 e 4 KiB con VLEN 1024. La gestione del contesto a lunghezza variabile e la manutenzione del codice auto-vettorizzato sono tra le difficoltà indicate nella descrizione ufficiale della sessione. Nell’esempio delle slide, l’uso è inoltre soggetto a restrizioni nei contesti hard IRQ e NMI.
