How to read these numbers. The headline in press coverage was “up to 15% gains.” That figure is real but narrow: it is LZ4 compression on one specific target. In the same slide deck, LZ4 compression on the other measured target is −7.5%, and that target’s geometric-mean gain across its whole system-benchmark suite is +0.1%. Nothing here is a general RISC-V Linux speedup. Every percentage below is tied to one workload, one operation and one hardware target, and the comparison baseline is a build compiled with -mtune. This is an initial investigation presented at a conference — not a benchmark regressions suite you can plan a shipping kernel around.
What was presented, where, and by whom
The primary source is a Linux Plumbers Conference 2026 session titled “Optimizing the kernel with vector”, given on October 6, 2026 at 3:40 PM in the “Small Theatre” of the Prague Congress Centre as part of the RISC-V microconference. The conference ran October 5–7, 2026.
The session abstract frames the work honestly as a revisit of something long considered off-limits in kernel development:
“The territory of using a larger context in the kernel-mode has been a forbidden topic since the existence of Linux. The use of SIMD unit in the kernel-mode is strictly restricted because the program is highly optimized for stack footprint, responsiveness, and maximum hardware compatibility. However, as hardware and compiler technologies advance, the benefit of enabling autovectorization has become more viable, and it might be a good time to revisit it.”
Two things are worth flagging about attribution, because they differ between sources. The LPC schedule lists the speaker as Tao Chiu; the slide deck’s own filename is LPC2026 Andy (3).pdf, and Phoronix’s write-up refers to Andy Chiu. We have not resolved which form is the intended public name, so we report both rather than picking one.
What “auto-vectorization” means in this context
Auto-vectorization is when a compiler identifies operations across multiple data elements and emits RISC-V Vector (RVV) instructions that process several elements per instruction. Today the RISC-V Linux kernel build does not make use of the Vector extension. This talk compiled a kernel where it does, then measured the result.
The slides describe Vector as off by default in the kernel context studied, and show kernel code making explicit use of vector APIs. That third point matters for anyone tempted to try this locally: enabling Vector for userspace is a different mechanism entirely, discussed below.
Results versus a -mtune build, workload by workload
These figures come from the presentation slides and compare an auto-vectorized kernel build against a build using -mtune. Note that the deck uses abbreviated hardware labels — ASC-X, ASC-S and K3 — whose full identities are not expanded in the material.
| Workload & operation | Target | Change vs -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 reported 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 rows are the clearest illustration of why single-number summaries mislead here. On the same workload, K3’s compression result is negative while its decompression result is positive; the counterpart target moves in the opposite direction. Compression and decompression are genuinely different code paths with different vector behaviour, so collapsing them into one “LZ4” figure hides both effects.
The system-wide number is not the headline number
The deck does not stop at microbenchmarks. For K3 it reports a geometric-mean gain of 0.1% across its system-benchmark suite, alongside regressions on that same target:
- LZ4 compression: −7.5%
- hackbench (process): −2.51%
- hackbench (thread): −4.06%
A strong single-workload result and a regression in another workload can coexist inside one benchmark set. That is the central practical takeaway: if you enable this today, you are trading tail latency in scheduling-sensitive paths for throughput in specific data-parallel ones.
The second, separate comparison
A later slide reports figures for a nonportable build targeted more closely at particular CPUs, under different comparison conditions. These numbers are much larger, which is exactly why they must not be mixed with the table above:
| Measurement | Target | Reported result |
|---|---|---|
| Geometric mean across 24 system benchmarks | — | +4.98% |
| zram-LZ4 | K3 | +34.8% |
| zram-LZ4 | ASC-X | +90.6% |
| zram-zstd | ASC-X | +35.4% |
| Btrfs create | ASC-X | +7.4% |
| Btrfs unlink | ASC-X | +7.2% |
This is the payoff that awaits per-CPU tuning — and the cost is right there in the label. A nonportable build means giving up the generic-kernel assumption, which for distributions is the entire point of shipping riscv64 images.
Why it costs more than a compiler flag
Context saving
Enabling Vector use means managing additional state. The deck gives register-state sizes for saving v0–v31:
| Vector length | Register state to save |
|---|---|
| VLEN 128 | 512 B |
| VLEN 1024 | 4 KiB |
Those figures describe the saved vector-register state — not total kernel memory overhead. But the direction is clear, and it collides directly with the reason kernel-mode SIMD has historically been restricted: the kernel is tuned for stack footprint and worst-case interrupt latency.
Where vector code may run
The slides’ example brackets kernel vector work with dedicated entry and exit calls, and notes restrictions on use in hard-interrupt and NMI contexts:
Restrictions apply. The presentation notes restrictions on using kernel vector sections in hard-interrupt and NMI contexts. The above is the pattern illustrated in the deck, not a drop-in recipe — consult the talk’s context rules and your kernel version before writing anything like it.
The session description also identifies two maintenance challenges explicitly: VLA (vector-length-agnostic) context management, and maintaining auto-vectorized code over time. The second is the one that decides whether this ever reaches mainline — a compiler’s willingness to vectorize a given loop changes between releases.
The userspace controls are not this
This is the most common misreading, so it is worth stating plainly. Linux’s documented RISC-V Vector controls apply to userspace:
PR_RISCV_V_SET_CONTROL/PR_RISCV_V_GET_CONTROL—prctl()options managing Vector availability for the calling thread/proc/sys/abi/riscv_v_default_allow— a default for new userspace processes
These are documented in the kernel’s RISC-V Vector documentation. They are not switches for compiler auto-vectorization inside the kernel. Letting a userspace thread use Vector instructions does nothing about the kernel’s own vector state; the kernel experiment uses separate APIs and separate state handling.
Toolchain, and a note on inference
The slides’ source-tree examples identify GCC 16.1 and -mtune=tt-ascalon-d8. Those examples illustrate compiler and tuning choices; they do not establish that every benchmark in the deck ran under exactly that configuration.
From that tuning flag and the ASC- prefix it is plausible that the ASC targets are Ascalon-class cores, and a target labelled K3 is consistent with SpacemiT’s K3 — a chip that appears in several previously published riscv64 Linux benchmark efforts. This paragraph is our inference, not something the slides state. Treat target identities as unconfirmed until the presenter or slides expand them.
Sources
- Primary: LPC 2026 session Optimizing the kernel with vector — schedule entry and abstract, presentation slides (PDF)
- Coverage: Michael Larabel, Auto Vectorizing The RISC-V Linux Kernel Shows Promising Results, Phoronix, 11 October 2026, 06:18 EDT — article
- Kernel documentation: RISC-V Vector Extension support
Related reading on Open RISC-V
- KVM on the SpacemiT K3 Reaches Stock Distros — the other side of K3 performance: a measured 13.4% compile regression and other mainline gaps
- Fedora 45 & GCC ICE — when vector-enabled builds fail outright on K1/K3
- SpacemiT K1 and K3 Devicetrees for Linux 7.4
如何阅读这些数字。 媒体报道的头条是「最多 15% 提升」。这个数字是真实的，但适用范围很窄：它指的是某一个特定硬件目标上的 LZ4 压缩。在同一份幻灯片里，另一个目标上的 LZ4 压缩是 −7.5%，而那个目标在整个系统基准套件上的几何平均增益只有 +0.1%。这里没有任何数字代表「RISC-V Linux 整体变快了」。下列每一个百分比都绑定于单一负载、单一操作、单一硬件目标，且对比基线是加了 -mtune 的编译版本。这是一场会议上报告的初步探索，不是可以据此规划量产内核的回归基准。
讲的是什么、在哪里讲、谁讲的
一手来源是 Linux Plumbers Conference 2026 议题 「Optimizing the kernel with vector」，时间为 2026 年 10 月 6 日 15:40，地点在布拉格会议中心 “Small Theatre”，属于 RISC-V 微会议 环节。大会会期为 2026 年 10 月 5–7 日。
议题摘要对这个工作的定位非常诚实 — 它是在重访一个长期被视为禁区的话题：
「在内核态使用更大的上下文，自 Linux 诞生以来一直是禁忌话题。内核态使用 SIMD 单元受到严格限制，因为内核程序是针对栈占用、响应性和最大硬件兼容性高度优化的。然而随着硬件与编译器技术进步，启用自动向量化的收益变得更加可行，也许是时候重新审视它了。」
关于演讲者姓名有两处值得说明的区别：LPC 议程页署名 Tao Chiu；而幻灯片文件本身名为 LPC2026 Andy (3).pdf，Phoronix 报道使用 Andy Chiu。我们无法确定哪个才是希望公开的正式写法，因此如实并列，不做取舍。
这里说的「自动向量化」是什么
自动向量化指编译器识别出作用于多个数据元素的操作，进而生成 RISC-V 向量（RVV）指令，使一条指令处理多个元素。目前 RISC-V Linux 内核的构建并不使用向量扩展。本次演讲编译了一个使用向量扩展的内核，然后测量了结果。
幻灯片说明：在所研究的内核上下文中，向量扩展默认是关闭的，并展示了内核代码显式调用向量 API。对想自己动手的人来说第三点尤其重要 — 让用户态使用向量是完全不同的另一套机制，见下文。
相对 -mtune 构建的结果，逐负载拆解
以下数字来自演讲幻灯片，对比对象是加了 -mtune 的内核构建。请注意幻灯片使用缩写硬件标签 — ASC-X、ASC-S、K3 — 材料中并未展开它们的完整身份。
| 负载与操作 | 目标 | 相对 -mtune 变化 | 测量背景 |
|---|---|---|---|
| LZ4（zram），压缩 | ASC-X | +15.1% | 压缩结果 |
| LZ4（zram），解压 | ASC-X | +1.0% | 解压结果 |
| LZ4（zram），压缩 | K3 | −7.5% | 压缩结果 |
| LZ4（zram），解压 | K3 | +9.4% | 解压结果 |
| Btrfs（fsmeta），create | ASC-X | +5.2% | create 操作 |
| Btrfs（fsmeta），unlink | ASC-X | +8.4% | unlink 操作 |
| Btrfs（fsmeta），create | K3 | +6.9% | create 操作 |
| Btrfs（fsmeta），unlink | K3 | +3.7% | unlink 操作 |
| XFS（fsmeta） | ASC-X | +2.5% / +5.0% | 元数据测试报告了两个结果 |
| XFS（fsmeta） | K3 | 不显著 | 元数据测试 |
| Nginx | ASC-S | +0.9% 至 +2.2% | 响应体 80 B 至 32 KB |
| Nginx | K3 | +0.3% 至 +1.9% | 响应体 80 B 至 32 KB |
LZ4 这几行最能说明单一数字为什么会误导。同一负载下，K3 的压缩是负收益，而它的解压是正收益；另一个目标的方向恰好相反。压缩和解压确实是不同的代码路径、有不同的向量行为，把它们折叠成一个「LZ4」数字会把两种效果同时掩盖掉。
系统级数字不是头条数字
幻灯片并未止步于微基准。对于 K3，它报告了整个系统基准套件的几何平均增益 0.1%，同一目标上还伴随以下退步：
- LZ4 压缩：−7.5%
- hackbench（进程）：−2.51%
- hackbench（线程）：−4.06%
一个负载上的漂亮结果，可以和同一基准集里另一个负载的退步并存。这是最务实的结论：如果今天启用它，你是在用调度敏感路径上的尾延迟，换取特定数据并行路径上的吞吐。
第二组、另一套对比条件下的数据
后面一张幻灯片报告了一组针对特定 CPU 更精细调优的不可移植构建数据，对比条件也不同。数字大得多，正因为如此更不能和上面的表混用：
| 测量项 | 目标 | 报告结果 |
|---|---|---|
| 24 项系统基准的几何平均值 | — | +4.98% |
| zram-LZ4 | K3 | +34.8% |
| zram-LZ4 | ASC-X | +90.6% |
| zram-zstd | ASC-X | +35.4% |
| Btrfs create | ASC-X | +7.4% |
| Btrfs unlink | ASC-X | +7.2% |
这是逐 CPU 调优能换来的收益 — 代价就写在「不可移植」四个字里。对发行版而言，放弃通用内核假设，恰恰等于放弃了发布统一 riscv64 镜像的全部意义。
为什么它不止是一个编译器开关的成本
上下文保存
启用向量意味着要多管理一份状态。幻灯片给出了保存 v0–v31 的寄存器状态体积：
| 向量长度 | 需保存的寄存器状态 |
|---|---|
| VLEN 128 | 512 B |
| VLEN 1024 | 4 KiB |
这些数字描述的是被保存的向量寄存器状态，不是内核的总内存开销。但趋势很明确，而且它正好撞上内核态 SIMD 历来受限制的原因 — 内核是为栈占用和最坏情况中断延迟调优的。
向量代码可以出现在哪里
幻灯片示例用专门的进入 / 退出调用把内核向量代码包起来，并注明在硬中断与 NMI 上下文中受限：
存在使用限制。 演讲指出内核向量段在硬中断与 NMI 上下文中受限。以上是幻灯片所示范式，不是可以直接照搬的配方 — 动手前请先依据该演讲的上下文规则和你所用的内核版本核实。
议题描述还明确点出了两项维护挑战：VLA（向量长度无关）上下文管理，以及自动向量化代码的长期维护。第二项才是决定它能否进主线的关键 — 编译器是否愿意向量化某个循环，会随版本变化。
用户态开关不是这个东西
这是最常见的误读，必须说清楚。Linux 有文档的 RISC-V 向量控制位只作用于用户态：
PR_RISCV_V_SET_CONTROL/PR_RISCV_V_GET_CONTROL— 管理调用线程向量可用性的prctl()选项/proc/sys/abi/riscv_v_default_allow— 新建用户进程的默认值
它们记录在内核的 RISC-V 向量文档中，不是内核内部编译器自动向量化的开关。让用户态线程使用向量指令，与内核自身的向量状态无关；内核侧的这套实验使用的是另一套 API 与状态处理。
工具链，以及一处推断标注
幻灯片的源码树示例显示了 GCC 16.1 与 -mtune=tt-ascalon-d8。这些示例用于说明编译器与调优选择，并不能证明每一项基准都跑在完全相同配置下。
由该调优参数和 ASC- 前缀推测，ASC 系列可能是 Ascalon 级核心；标为 K3 的目标则与进迭时空 K3 相符 — 这款芯片出现在多个已公开的 riscv64 Linux 基准工作中。这一段是我们的推断，并非幻灯片所述。 在演讲者或幻灯片正式展开之前，目标机器的身份应视为未确认。
来源
- 一手：LPC 2026 议题 Optimizing the kernel with vector — 议程页与摘要、演讲幻灯片 PDF
- 报道：Michael Larabel，Auto Vectorizing The RISC-V Linux Kernel Shows Promising Results，Phoronix，2026 年 10 月 11 日 06:18 EDT — 文章链接
- 内核文档：RISC-V Vector Extension support
站内延伸阅读
- SpacemiT K3 上的 KVM 已进入发行版 — K3 性能的另一面：实测 13.4% 编译退步及其他主线缺口
- Fedora 45 与 GCC ICE — 当启用向量的构建在 K1/K3 上直接编译失败时
- SpacemiT K1 与 K3 面向 Linux 7.4 的设备树
Автовекторизация ядра RISC-V на LPC 2026
На конференции Linux Plumbers Conference 2026 прошла 20-минутная сессия «Optimizing the kernel with vector» в рамках RISC-V-микроконференции (6 октября 2026, Прага). В докладе рассмотрена сборка ядра Linux для RISC-V с автовекторизацией и приведены первоначальные измерения.
Главное: заголовок в прессе «до 15%» относится к LZ4-сжатию на одной конкретной цели. На другой цели LZ4-сжатие даёт −7.5%, а среднее геометрическое по системным тестам этой цели — всего +0.1%. Это не общая прибавка RISC-V Linux: результаты зависят от нагрузки, операции и оборудования; база сравнения — сборка с -mtune.
Почему это не бесплатно: требуется сохранение большего контекста (512 Б при VLEN 128 и 4 КиБ при VLEN 1024 для v0–v31), есть ограничения в контекстах аппаратных прерываний и NMI, а наилучший результат требует сборки под конкретный CPU — то есть потери переносимости ядра.
Autovectorización del kernel RISC-V en LPC 2026
En Linux Plumbers Conference 2026 se presentó la sesión «Optimizing the kernel with vector», dentro de la microconferencia RISC-V (6 de octubre de 2026, Praga): una medición inicial de un kernel Linux RISC-V compilado con autovectorización.
Lo esencial: el titular de prensa «hasta 15%» corresponde a la compresión LZ4 en un objetivo concreto. En el otro objetivo medido, la compresión LZ4 cae −7.5% y la media geométrica del conjunto de pruebas de sistema es de apenas +0.1%. No se trata de una aceleración general de RISC-V Linux: cada cifra depende de carga, operación y hardware, y la base de comparación es una compilación con -mtune.
Coste: hay que gestionar más contexto (512 B con VLEN 128 y 4 KiB con VLEN 1024 para v0–v31), existen restricciones en contextos de interrupción hardware y NMI, y obtener el mejor resultado exige compilar por CPU, es decir, renunciar a la portabilidad del kernel.
Autovectorisation du noyau RISC-V à LPC 2026
Linux Plumbers Conference 2026 a accueilli la session «Optimizing the kernel with vector» dans la microconférence RISC-V (6 octobre 2026, Prague) : une première série de mesures d’un noyau Linux RISC-V compilé avec autovectorisation.
L’essentiel : le titre de presse « jusqu’à 15% » concerne la compression LZ4 sur une cible précise. Sur l’autre cible mesurée, la compression LZ4 recule de −7,5% et la moyenne géométrique de la suite de tests système n’est que de +0,1%. Ce n’est pas une accélération générale de RISC-V Linux : chaque chiffre dépend de la charge, de l’opération et du matériel, la référence étant une compilation avec -mtune.
Coût : il faut gérer plus de contexte (512 o à VLEN 128 et 4 Kio à VLEN 1024 pour v0–v31), l’usage est restreint en contexte d’interruption matérielle et de NMI, et le meilleur résultat exige une compilation par CPU, donc la perte de la portabilité du noyau.
Autovektorisierung des RISC-V-Kernels auf der LPC 2026
Auf der Linux Plumbers Conference 2026 wurde im Rahmen der RISC-V-Mikrokonferenz die Session „Optimizing the kernel with vector“ gehalten (6. Oktober 2026, Prag): eine erste Messreihe zu einem autovektorisiert kompilierten RISC-V-Linux-Kernel.
Kernaussage: Die Schlagzeile „bis zu 15%“ bezieht sich auf die LZ4-Kompression auf einem bestimmten Zielsystem. Auf dem anderen gemessenen System sinkt die LZ4-Kompression um −7,5%, und das geometrische Mittel über die System-Benchmarks beträgt dort nur +0,1%. Das ist keine allgemeine Beschleunigung von RISC-V-Linux: Jede Zahl hängt an Last, Operation und Hardware; Vergleichsbasis ist ein Build mit -mtune.
Kosten: Mehr Kontext muss gesichert werden (512 B bei VLEN 128 und 4 KiB bei VLEN 1024 für v0–v31), die Nutzung in Hard-IRQ- und NMI-Kontexten ist eingeschränkt, und das beste Ergebnis erfordert pro-CPU-Kompilierung — also den Verlust der Kernel-Portabilität.
بردارسازی خودکار هسته RISC-V در LPC 2026
در کنفرانس Linux Plumbers Conference 2026، نشست «Optimizing the kernel with vector» در بخش RISC-V برگزار شد (۶ اکتبر ۲۰۲۶، پراگ): نخستین سنجش یک هسته لینوکس RISC-V که با بردارسازی خودکار کامپایل شده است.
نکته اصلی: تیتر مطبوعاتی «تا ۱۵٪» مربوط به فشردهسازی LZ4 روی یک هدف مشخص است. روی هدف دیگر، فشردهسازی LZ4 −7.5% افت دارد و میانگین هندسی کل مجموعه بنچمارکهای سیستمی آن تنها +0.1% است. این یک افزایش سرعت کلی برای RISC-V Linux نیست: هر عدد به یک بار کاری، یک عمل و یک سختافزار وابسته است و مبنای مقایسه، کامپایل با -mtune است.
هزینه: مدیریت کانتکست بیشتر لازم است (۵۱۲ بایت در VLEN 128 و ۴ کیبیبایت در VLEN 1024 برای v0–v31)، استفاده در کانتکست وقفه سخت و NMI محدود است، و بهترین نتیجه نیازمند کامپایل جداگانه برای هر CPU — یعنی از دست رفتن قابلیت حمل هسته — است.