← Back to Blog
RISC-V Development

openKylin 3.0 Moves to Linux 7.0 with RVA23 Support: 36.5x FP16 Inference Gain from RVV Optimisation

2026-09-02 6 min read EN
openKylin Linux 7.0 RVA23 RVV GCC 15 LLVM 22 glibc 2.42 Rust post-quantum LoongArch

Table of Contents

Published: 2026-09-02 | Category: RISC-V Development | Reading time: ~6 min

OpenAtom openKylin 3.0 has been released, moving the distribution's kernel from Linux 6.6 to Linux 7.0 and updating more than 180 core components. For RISC-V developers, two lines matter more than the rest: the distribution supports the RVA23 standard, and after RVV instruction optimisation it reports 2× to 5× faster AI inference in FP32 and up to 36.5× in FP16 on RISC-V platforms.

The release coverage is dated 31 August 2026.

The toolchain baseline moves substantially

openKylin 3.0 aligns with current upstream toolchain releases:

For anyone maintaining riscv64 builds, the LLVM 22 step is the significant one. Recent LLVM releases are where the RISC-V backend's support for newer ratified extensions has landed, including experimental assembler support for several newer ISA extensions and additional processor scheduling models. A distribution shipping LLVM 22 as its default means those code-generation paths are available without a custom toolchain build.

GCC 15 and glibc 2.42 bring the compiler and C-library side forward together, which matters on RISC-V more than on mature architectures: support in glibc and GCC has to land in step, and keeping them aligned avoids the bug class where one half assumes an extension the other does not emit.

RVA23 support: what it unlocks

openKylin 3.0 provides same-source support for x86, ARM, RISC-V, and LoongArch, and supports the RVA23 standard.

RVA23's practical effect is worth restating because it is the mechanism behind the performance numbers below. The profile makes RVV 1.0 vector processing, the Hypervisor extension, and bit manipulation mandatory. Before a ratified profile fixed that baseline, a distribution building one riscv64 archive had to target the weakest shipping core, which meant vector code was excluded from default package builds regardless of what the hardware supported. With RVA23 declared, packages can be built assuming vector instructions exist — the precondition for the reported speedups, not the speedups themselves.

The RVV optimisation numbers, and how to read them

openKylin reports that on RISC-V platforms, after RVV instruction optimisation:

The FP16 figure is large enough to warrant scrutiny, and the mechanism is probably straightforward rather than exotic. On a core without usable vector support, FP16 inference frequently runs emulated or falls back to FP32 with conversion overhead, because the hardware has no native half-precision path. Once RVV 1.0 is available and the compiler targets it, the same operations run in native vector lanes. The multiple is a comparison against a degraded baseline, not against a well-optimised scalar FP32 path.

That does not make it useless — it is a genuine measure of what RVV unlocks for a default distribution build. But it should be described as a gain against an unvectorised baseline, not as a 36.5× architectural advantage over other architectures' FP16 implementations.

What is not stated in the source: which RISC-V hardware was measured (SoC, core, vector length, clock); which model, framework, and inference runtime were used; batch size, thread count, and whether the figure is single-inference or sustained throughput; whether the baseline is scalar FP32 on the same core or FP16 without RVV; which libraries were vectorised; and whether the optimised paths are upstream or distribution-local patches. Every one of those should be asked for before the figure is repeated as a benchmark result.

Rust in the kernel and in core userspace

openKylin 3.0 supports Rust for Linux, allowing developers to write peripheral drivers in Rust. The release also states that wget and time are among the first system tools to have been rewritten in Rust.

The RISC-V relevance is concrete. Driver development is where new-architecture support tends to lag — peripheral drivers are the last thing ported and the first thing to break. Making Rust a supported language for drivers on a distribution that also targets riscv64 gives teams a second option for new peripheral work, with the memory-safety properties that come with it.

Security and post-quantum cryptography

The release integrates the three NIST post-quantum cryptography standards — ML-KEM, ML-DSA, and SLH-DSA — exposed at system level through the openHiTLS cryptographic suite, paired with a TPM trusted boot chain for chip-to-system trust.

For RISC-V this is worth noting because post-quantum primitives are compute-heavy and benefit directly from vector execution: ML-KEM and ML-DSA are polynomial-arithmetic workloads that map well onto RVV. A distribution with both PQC in its crypto suite and a vector baseline in its build flags is positioned to make that path fast — though the source claims no specific PQC optimisation for RISC-V.

Beyond the desktop

openKylin 3.0 also adds a unified system-level agent runtime (model, memory, tools, permissions, and desktop capability under one architecture), with agents including KylinBot, WorkBuddy, OpenClaw, and Raccoon Work invoking desktop capability through MCP. The desktop moves to UKUI 4.24 with voice, air-gesture, and touchpad interaction, and 18 languages were added.

On hardware coverage, it states adaptation for embodied-intelligence devices including the Linglong humanoid robot, AI unmanned vehicles, and AI robotic arms, alongside multi-architecture industrial hardware, plus 20+ Docker images for AI, cloud, and big-data scenarios.

Why this matters outside the distribution's own user base

The pattern to watch is not openKylin specifically. It is that a distribution has moved its entire toolchain forward by roughly a year of upstream releases at once, declared a ratified profile as its target, and published a measured number for what vector execution buys on that target.

That combination — modern compiler, declared profile baseline, measured vector gain — is the set of conditions under which portable riscv64 software stops being a per-board effort. The remaining gap is reproducibility: the FP16 figure needs hardware, runtime, and baseline details before it means anything beyond "RVV matters."

Sources

  1. 科技日报 (Science and Technology Daily) — "openKylin 3.0发布 系统内核升级至Linux 7.0", published 31 August 2026 19:41:27: https://www.stdaily.com/web/gdxw/2026-08/31/content_572715.html
  2. ZDNet — "You can use Linux 7.0 on these 7 distros today — here's what to expect" (context on Linux 7.0 Rust status and cross-compilation support for RISC-V; secondary source): https://zdnet.com/article/try-new-linux-7-0-kernel-on-these-distributions/
  3. Phoronix / LLVM release notes — LLVM 23.1.0 (context on RISC-V backend work in recent LLVM releases; secondary source): https://linuxier.com/blog/llvm-clang-23-1-amd-zen6-nvidia-rigel-released
  4. openKylin official site: https://www.openkylin.top

Verification notes

Open RISC-V — RISC-V Silicon & Development Board Store — open-riscv.com