Asterinas 0.19, the Linux-compatible kernel in Rust: I reran its benchmarks on my machine and 13 of 23 hold up

Asterinas is a kernel written from scratch in Rust that speaks the same interface as Linux: many programs compiled for Linux run on it unchanged, as long as they use what it already implements. On October 13 it released version 0.19, with graphics, a fourth CPU architecture and a new device model.

That is not what caught my eye. The project publishes a performance comparison against Linux every night: 113 current metrics on the dashboard I downloaded, from boot to nginx and redis, with the scripts in the open. It is rare for a project to expose itself like that. So I did what that transparency allows: I took their scripts, ran them on my machine and compared.

What makes Asterinas different

Linux is written in C and has accepted parts in Rust since 2022, but its core is still C. Asterinas started from scratch in Rust and splits its code in two layers. At the bottom, a small layer called OSTD holds all the unsafe code, the code that can break memory safety. Above it, the rest of the kernel is safe Rust. They call it a framekernel: the idea is that auditing memory safety only takes reviewing the bottom layer.

According to its announcement, the project has passed 250,000 lines, about 200,000 of them Rust, and its README says it implements more than 240 Linux system calls. Those are the project’s figures; I did not count them.

How I measured

Before running anything I wrote down a measurement sheet: which 23 benchmarks from their dashboard I would rerun, how many times, and what counts as a result that “reproduces”. The rule: the same kernel wins as on their dashboard, and the ratio between the two stays within a factor of 1.25 of the published one (1.25 included).

I used their script, bench_linux_and_aster.sh, untouched, inside the same Docker image their CI uses. The script starts a virtual machine with each kernel, runs the same test in both and saves both results:

I ran each test three times, in a different shuffled order each repetition, on my Ryzen 7 7800X3D running NixOS (the machine is called fedora, its name from before the migration). If the ranges of the three Linux values and the three Asterinas values overlap, I count it as “no difference measured”, not as anyone’s win. It is a descriptive rule, not a statistical test: if all six values come from the same continuous distribution (exchangeable, no real difference), the ranges come out separated by chance one time in ten.

A detail I found reading the scripts: the two virtual machines do not see the same processor. Asterinas gets an Icelake model with the virtualization extension on; Linux gets the same model with PCID turned off. And since my CPU is AMD, QEMU warns that many of those Intel features do not exist. I come back to this below.

Boot: twice as fast

Asterinas reaches the benchmark’s first line in 0.34 seconds; Linux, in 0.70: Linux takes 2.06 times as long as Asterinas. The project’s dashboard publishes 0.31 against 0.82, a ratio of 2.65. The advantage holds on my machine, somewhat smaller. By the sheet’s rule that does not count as an exact reproduction, but the underlying result, that it boots faster, holds.

The 23 benchmarks

Each row is a test. The dot is my median of three runs; the bar, the range; the diamond, what the project publishes. Right of 1, Asterinas wins; left of 1, Linux wins.

Where Asterinas wins: boot, the latency of sysbench’s thread benchmark (6.1 times better; they publish 3.9), local TCP latency (1.35 times), page faults (1.12 times) and, barely, exec and context switches.

Where Linux wins, 13 of 23:

• The simplest system calls. getppid, which does almost nothing, takes 0.083 microseconds on Asterinas and 0.039 on Linux: more than twice as long.
• Opening, reading and writing files, between 1.8 and 2.4 times slower on Asterinas.
• nginx with 20 connections: Asterinas transfers 22% of the data per second Linux transfers.
• The scheduler with 8 CPUs: in schbench, the 99th percentile request latency is 13 times worse on Asterinas, 89 milliseconds against 6.8.
• SQLite on ext2, 46% slower; on RAM, only 6%.

No difference measured: memcached, redis GET and SET, and sysbench’s CPU benchmark, where both kernels give exactly the same (it is pure user-space arithmetic; the kernel should not matter there).

What does not reproduce

Of the 13 that do reproduce, one, redis SET, meets the rule numerically but its ranges overlap: no difference measured. One more caveat: for SQLite I took total time as the metric, a choice made in the analysis script and not written in the sheet.

In 10 of the 23 tests my result falls outside the rule. In most, the same kernel wins but by a different margin: nginx with 20 connections gave me 22% where they publish 12%; schbench, 13 times worse where they publish 36.

The winner flips in three, and only two are clear inversions, without overlap: fork and context switches. In memcached the ranges overlap. In sysbench’s CPU benchmark my three ratios are exactly 1: it is a tie, with no winner to flip.

The case I find most interesting is fork. On their dashboard, Linux and Asterinas are close to a tie, with Asterinas barely ahead: 132 against 130 microseconds. On my machine, Linux takes 69 and Asterinas 103: 1.5 times slower, and Asterinas was slower in all three repetitions.

Is it the virtual CPU?

A reasonable suspect is the CPU model: an Intel simulated on an AMD, and a different one for each kernel. So, with the results already in, I reran six of the tests with -cpu host for both virtual machines, which passes the real processor through. It is an exploratory test, declared as such in the sheet.

On these six tests, switching to -cpu host did not remove the gaps with the dashboard:

Ratio of Linux over Asterinas (all six are latencies or durations), median of three runs; above 1 is better for Asterinas.

fork is still 1.5 times slower on Asterinas and getppid more than twice. On threads the advantage drops by 4%, and on context switches the median ratio sits at 1. It is not an equivalence test: I ran the two conditions at different times and without controlling the load. It is consistent with the simulated CPU model not explaining the gaps with the dashboard, but without controlling the load it does not prove it. I did not isolate how much the processor, the commit, the host kernel, QEMU or the load contribute; their CI runs on a self-hosted runner whose hardware I did not find in their sources.

What this measurement does not cover

• A single AMD machine. The project’s dashboard runs on a self-hosted runner whose hardware I did not find documented. I compare ratios, not absolute values.
• Not exactly the same commit. I ran the v0.19.0 tag; the dashboard I copied belongs to a commit five changes later: three documentation changes, one that changes how an exFAT test image is created and one that fixes timerfd. From their descriptions none touches what I measured, but I did not isolate their effect by running that commit.
• Three repetitions per test. Few: with three repetitions any uncertainty estimate is fragile and depends on the method and its assumptions. In schbench each p99 comes from the many requests of one run, but there are only three p99 values per kernel.
• The host was not idle. It ran other services: Keycloak, a chat API, a sandbox. I did not measure how much they interfered.
• One CPU per virtual machine in almost every test, as in their setup.
• 23 tests from a dashboard of 113 metrics. Some tests yield several metrics, and the dashboard I downloaded also keeps 20 metrics from an older commit. I picked them before running and they are listed in the sheet; I did not measure fio or the virtual-network ones at several sizes, and they do not represent the whole dashboard.
• Before the counted runs there was an aborted attempt (a misspelled job name) and a bug in my script that discarded a result. Neither went into the numbers; the 69 full run logs are published.
• I did not record CPU affinity, SMT, the frequency governor or the host’s load during each test.

When I would use it

I would use it to experiment with a Rust kernel that runs real software, and I would watch it closely as a guest kernel for small virtual machines: in my QEMU test it booted in a third of a second, and according to its announcement it already runs as a Firecracker guest.

I would not use it yet to serve traffic: with nginx, files and the multi-core scheduler, Linux is well ahead. The project knows; it publishes it every night.

---

Measured on October 14, 2026 on an AMD Ryzen 7 7800X3D with 30 GB of RAM, NixOS 26.05 with kernel 6.18.55, KVM and QEMU 10.2.1. Asterinas v0.19.0 with the asterinas/kernel-dev:0.19.0-20261012 image; Linux 6.16.0 as guest, the one the project’s script downloads. 23 benchmarks, 3 repetitions each.

Sources

• Announcing Asterinas 0.19.0. The release announcement, with the lines-of-code and contributor figures.
• Asterinas repository. The code, the MPL-2.0 license and the benchmark scripts I used, in test/initramfs/src/benchmark/.
• Asterinas x86-64 benchmark dashboard. The results they publish every night, which I compared against.
• The framekernel architecture. The explanation of the split between OSTD and the rest of the kernel.
• Rust in the Linux kernel. The official documentation of Rust support in Linux.
• Linux 6.1 on Kernel Newbies. The release that brought initial Rust support, out on 11 December 2022.
• My scripts, the measurement sheet and the raw data. The 69 runs with their full logs, the 18 exploratory ones with the -cpu host change, and the analysis. python3 analyze.py > results.json.

Frequently asked questions

What is Asterinas?

An operating system kernel written from scratch in Rust that implements the Linux interface: according to its README, more than 240 system calls, so many Linux programs run without recompiling them. It is free software under the MPL-2.0 license. Its architecture, which its authors call a framekernel, confines all unsafe Rust code to a small layer called OSTD.

Is it faster than Linux?

It depends on what you measure. On my machine Linux took 2.06 times as long as Asterinas to boot, and on the latency of sysbench's thread benchmark Asterinas was 6.1 times better. Linux was faster in 13 of 23 tests, including the simplest system calls, file reads and writes, nginx with 20 connections and scheduler latency with 8 CPUs.

Do the project's published results reproduce?

In 13 of 23 tests they do: the same kernel wins and the ratio stays within a factor of 1.25 of the published one (1.25 included). In the other 10 the magnitude or the winner changes. The winner flips without overlap in two: fork, which on their dashboard is close to a tie with Asterinas barely ahead and on my machine took 1.5 times as long on Asterinas, and context switches.

How can these measurements be repeated?

With the project's own script, bench_linux_and_aster.sh, inside its CI Docker image, on a machine with KVM. My scripts to run the three repetitions and analyze them, the measurement sheet and the raw data are in the gist linked in the sources.

Is it ready for production?

Not yet as a general Linux replacement, and the project does not present it that way. Where it makes the most sense today is as a guest kernel in small virtual machines, for example in Kata-style isolated containers, where booting fast and having less unsafe code matter more than nginx throughput.