The Linux Plumbers Conference 2026 slides report initial RISC-V Linux kernel vectorization results that vary by workload and hardware target—not a uniform speedup. LZ4 compression, for example, ranges from +15.1% on ASC-X to −7.5% on K3, relative to mtune. The conference ran October 5–7, 2026; its presentation slides break the results out by operation and target, while the conference description frames the work as an initial investigation.
What kernel auto-vectorization means here
Auto-vectorization is when a compiler identifies suitable operations on data and generates vector instructions that can process multiple elements at once. The presentation examines that approach in a RISC-V Linux kernel build. It describes Vector as off by default in the kernel context under study and shows kernel code making explicit use of vector APIs.
The distinction matters: these are experiments, not a general performance guarantee for RISC-V Linux. Their figures compare results with mtune, and the outcome changes with the operation and target.
Results vary by workload and target
The slide deck reports the following changes over mtune:
| Workload and operation | Hardware target | Reported change over mtune | Measurement context |
| LZ4 (zram), compression | ASC-X | +15.1% | Compression result |
| LZ4 (zram), decompression | ASC-X | +1.0% | Decompression result |
| LZ4 (zram), compression | K3 | −7.5% | Compression result |
| LZ4 (zram), decompression | K3 | +9.4% | Decompression result |
| Btrfs (fsmeta), create | ASC-X | +5.2% | Create operation |
| Btrfs (fsmeta), unlink | ASC-X | +8.4% | Unlink operation |
| Btrfs (fsmeta), create | K3 | +6.9% | Create operation |
| Btrfs (fsmeta), unlink | K3 | +3.7% | Unlink operation |
| XFS (fsmeta) | ASC-X | +2.5%; 5.0% | Two results for the metadata test |
| XFS (fsmeta) | K3 | Not significant | Metadata test |
| Nginx | ASC-S | 0.9% to +2.2% | Serving sizes from 80 B to 32 KB |
| Nginx | K3 | 0.3% to +1.9% | Serving sizes from 80 B to 32 KB |
The LZ4 figures show why compression and decompression need separate rows: K3’s compression result is negative even though its decompression result is positive. Btrfs also varies by operation, and the K3 XFS result is labeled not significant. The percentages describe specific slide benchmarks, not a single score for every RISC-V processor or kernel workload.
Some RISC-V readers also questioned the changing target labels, particularly ASC-X versus ASC-S, in a discussion on r/RISCV. The slides use those abbreviated labels; their full hardware identities are not needed to report the stated results.
A benchmark peak is not a system-wide result
For K3, the presentation reports a 0.1% geometric-mean gain across its system benchmarks. It also lists negative results for LZ4 compression (−7.5%) and hackbench process and thread tests (−2.51% and −4.06%). A strong result in one workload can therefore coexist with regressions elsewhere in the same benchmark set.
A separate slide reports results for a nonportable build targeted more closely to particular CPUs, under different comparison conditions. It gives a +4.98% geometric mean across 24 system benchmarks and +34.8% for zram-LZ4 on K3. For ASC-X, it reports +90.6% for zram-LZ4, +35.4% for zram-zstd, and +7.4% and +7.2% for Btrfs create and unlink. These figures belong to that separate comparison, not the mtune results in the table.
The slides’ source-tree examples identify GCC 16.1 and -mtune=tt-ascalon-d8. They illustrate compiler and tuning choices; they do not establish that every benchmark used that exact configuration.
Userspace Vector controls are separate from kernel use
Linux’s documented RISC-V Vector controls apply to userspace. The PR_RISCV_V_SET_CONTROL and PR_RISCV_V_GET_CONTROL prctl() options manage Vector availability for the calling thread, while /proc/sys/abi/riscv_v_default_allow sets a default for new userspace processes. Linux’s RISC-V Vector documentation describes those interfaces; they are not switches for compiler auto-vectorization inside the kernel.
The kernel experiment uses separate APIs and state handling. That distinction is central to the presentation: letting a userspace thread use Vector instructions does not itself handle the kernel’s vector state when kernel code uses the extension.
Context handling adds engineering work
The conference description identifies vector-length-agnostic (VLA) context management and maintenance of auto-vectorized code as challenges. VLA code is designed to work across different vector lengths, but kernel use still requires managing vector state. The slides’ example brackets kernel vector work with kernel_vector_begin() and kernel_vector_end() and notes restrictions on use in hard interrupt and NMI contexts.
The deck also gives register-state sizes for saving v0–v31: 512 B at VLEN 128 and 4 KiB at VLEN 1024. Those figures describe the saved vector-register state. They are not total kernel memory overhead. The example’s context rules and CPU-specific tuning are part of the work involved in moving from a promising benchmark to maintainable kernel code.
