Asterinas 0.19, el kernel en Rust compatible con Linux: repetí sus benchmarks en mi máquina y 13 de 23 se sostienen

Asterinas es un kernel escrito desde cero en Rust que habla la misma interfaz que Linux: muchos programas compilados para Linux corren encima sin cambios, en la medida en que usen lo que ya implementa. El 13 de octubre sacó la versión 0.19, con gráficos, una cuarta arquitectura de CPU y un modelo de dispositivos nuevo.

Lo que más me llamó la atención no fue eso. El proyecto publica cada noche una comparación de rendimiento contra Linux: 113 métricas vigentes en el tablero que bajé, del arranque a nginx y redis, con los scripts a la vista. Es raro que un proyecto se exponga así. Así que hice lo que permite esa transparencia: tomé sus scripts, los corrí en mi máquina y comparé.

Qué hace distinto a Asterinas

Linux está escrito en C y desde 2022 acepta partes en Rust, pero el núcleo sigue siendo C. Asterinas empezó de cero en Rust y separa el código en dos capas. Abajo, una capa chica llamada OSTD concentra todo el código unsafe, el que puede romper la seguridad de memoria. Arriba, el resto del kernel está en Rust seguro. Lo llaman framekernel: la idea es que para auditar la seguridad de memoria baste revisar la capa de abajo.

Según su anuncio, el proyecto ya pasó las 250 000 líneas, unas 200 000 en Rust, y según su README implementa más de 240 llamadas al sistema de Linux. Son cifras del proyecto; no las conté.

Cómo medí

Antes de correr nada dejé escrita una ficha: qué 23 benchmarks de su tablero iba a repetir, cuántas veces, y qué cuenta como que un resultado «se reproduce». La regla: que gane el mismo kernel que en su tablero y que la proporción entre los dos quede dentro de un factor 1,25 de la publicada (1,25 incluido).

Usé su script, bench_linux_and_aster.sh, sin tocarlo, dentro de la misma imagen de Docker que usa su CI. El script levanta una máquina virtual con cada kernel, corre la misma prueba en las dos y guarda ambos resultados:

Corrí cada prueba tres veces, en un orden mezclado distinto en cada repetición, en mi Ryzen 7 7800X3D con NixOS (la máquina se llama fedora; es su nombre de antes de migrar). Si los rangos de los tres valores de Linux y los tres de Asterinas se solapan, lo cuento como «sin diferencia medida», no como victoria de nadie. Es una regla descriptiva, no una prueba estadística: si los seis valores vienen de una misma distribución continua (intercambiables, sin diferencia real), los rangos quedan separados por azar una de cada diez veces.

Un detalle que encontré revisando los scripts: las dos máquinas virtuales no ven el mismo procesador. A Asterinas le asignan un modelo Icelake con la extensión de virtualización activada; a Linux, el mismo modelo pero con PCID desactivado. Y como mi CPU es AMD, QEMU avisa que muchas de esas funciones de Intel no existen. Vuelvo sobre esto más abajo.

El arranque: el doble de rápido

Asterinas llega a la primera línea del benchmark en 0,34 segundos; Linux, en 0,70: Linux tarda 2,06 veces lo que Asterinas. El tablero del proyecto publica 0,31 contra 0,82, una proporción de 2,65. La ventaja se mantiene en mi máquina, algo menor. Por la regla de la ficha eso no cuenta como reproducción exacta, pero el resultado de fondo, que arranca más rápido, se sostiene.

Los 23 benchmarks

Cada fila es una prueba. El punto es mi mediana de tres corridas; la barra, el rango; el rombo, lo que publica el proyecto. A la derecha del 1 gana Asterinas, a la izquierda gana Linux.

Donde gana Asterinas: el arranque, la latencia del banco de hilos de sysbench (6,1 veces mejor; ellos publican 3,9), la latencia de TCP local (1,35 veces), los fallos de página (1,12 veces) y, por poco, exec y el cambio de contexto.

Donde gana Linux, que son 13 de 23:

• Las llamadas al sistema más simples. getppid, que casi no hace nada, tarda 0,083 microsegundos en Asterinas y 0,039 en Linux: más del doble.
• Abrir, leer y escribir archivos, entre 1,8 y 2,4 veces más lento en Asterinas.
• nginx con 20 conexiones: Asterinas transfiere el 22 % de los datos por segundo que transfiere Linux.
• El planificador con 8 CPU: en schbench, la latencia de las peticiones en el percentil 99 es 13 veces peor en Asterinas, 89 milisegundos contra 6,8.
• SQLite sobre ext2, un 46 % más lento; sobre RAM, apenas un 6 %.

Sin diferencia medida: memcached, redis GET y SET, y el banco de CPU de sysbench, donde los dos kernels dan exactamente lo mismo (es pura aritmética en espacio de usuario; ahí el kernel no debería importar).

Lo que no se reproduce

De las 13 que sí se reproducen, una, redis SET, cumple la regla en los números pero sus rangos se solapan; sin diferencia medida. Una precisión más: para SQLite tomé como métrica el tiempo total, una elección que quedó en el script de análisis y no escrita en la ficha.

En 10 de las 23 pruebas mi resultado no cae dentro de la regla. En la mayoría gana el mismo, pero con otra magnitud: nginx con 20 conexiones me dio 22 % donde ellos publican 12 %; schbench, 13 veces peor donde ellos publican 36.

El ganador se da vuelta en tres, y solo dos son inversiones claras, sin solapamiento: fork y el cambio de contexto. En memcached los rangos se solapan. En el banco de CPU de sysbench mis tres proporciones dan exactamente 1: es un empate, no hay ganador que se dé vuelta.

El caso que más me interesa es fork. En su tablero, Linux y Asterinas casi empatan, con Asterinas apenas adelante: 132 contra 130 microsegundos. En mi máquina, Linux tarda 69 y Asterinas 103: 1,5 veces más lento, y Asterinas fue más lento en las tres repeticiones.

¿Es por el procesador virtual?

Una sospecha razonable es el modelo de CPU: un Intel simulado sobre un AMD, y distinto para cada kernel. Así que, ya con los resultados a la vista, repetí seis de las pruebas con -cpu host para las dos máquinas virtuales, que les pasa el procesador real. Es una prueba exploratoria, declarada como tal en la ficha.

En estas seis pruebas, cambiar a -cpu host no eliminó las diferencias con el tablero:

Proporción Linux sobre Asterinas (las seis son latencias o duraciones), mediana de tres corridas; más de 1 es mejor para Asterinas.

fork sigue siendo 1,5 veces más lento en Asterinas y getppid más del doble. En hilos la ventaja baja un 4 %, y en el cambio de contexto la mediana de la proporción queda en 1. No es una prueba de equivalencia: corrí las dos condiciones en momentos distintos y sin controlar la carga. Es consistente con que el modelo de CPU simulado no explique las diferencias con el tablero, pero sin controlar la carga no lo demuestra. No aislé cuánto aportan el procesador, el commit, el kernel del host, QEMU o la carga; su CI corre en un runner autogestionado cuyo hardware no encontré en sus fuentes.

Lo que esta medición no cubre

• Una sola máquina AMD. El tablero del proyecto corre en un runner autogestionado cuyo hardware no encontré documentado. Comparo proporciones, no valores absolutos.
• No es exactamente el mismo commit. Corrí la etiqueta v0.19.0; el tablero que copié corresponde a un commit cinco cambios posterior: tres de documentación, uno que cambia cómo se crea una imagen de prueba exFAT y uno que corrige timerfd. Por lo que describen, ninguno toca lo medido, pero no aislé su efecto corriendo ese commit.
• Tres repeticiones por prueba. Son pocas: con tres repeticiones, cualquier estimación de incertidumbre es frágil y depende del método y sus supuestos. En schbench, cada p99 sale de las muchas peticiones de una corrida, pero son solo tres p99 por kernel.
• El host no estaba vacío. Tenía otros servicios corriendo: Keycloak, una API de chat, un sandbox. No medí cuánto interfirieron.
• Un CPU por máquina virtual en casi todas las pruebas, como en su configuración.
• 23 pruebas de un tablero de 113 métricas. Algunas pruebas dan varias métricas, y el tablero que bajé guarda además 20 métricas de un commit anterior. Las elegí antes de correr y están enumeradas en la ficha; no medí fio ni los de red virtual con varios tamaños, y no representan el tablero completo.
• Antes de las corridas contadas hubo un intento abortado (un nombre de job mal escrito) y un error de mi script que descartó un resultado. Ninguno entró en los números; los 69 registros completos están publicados.
• No registré la afinidad de CPU, el SMT, el gobernador de frecuencia ni la carga del host durante cada prueba.

Cuándo lo usaría

Lo usaría para experimentar con un kernel en Rust que corre software real, y lo miraría con atención como kernel invitado de máquinas virtuales chicas: en mi prueba con QEMU arrancó en un tercio de segundo, y según su anuncio ya funciona como invitado de Firecracker.

No lo usaría todavía para servir tráfico: con nginx, archivos y el planificador con varios núcleos, Linux le saca ventajas grandes. El proyecto lo sabe; lo publica cada noche.

---

Medido el 14 de octubre de 2026 en un AMD Ryzen 7 7800X3D con 30 GB de RAM, NixOS 26.05 con kernel 6.18.55, KVM y QEMU 10.2.1. Asterinas v0.19.0 con la imagen asterinas/kernel-dev:0.19.0-20261012; Linux 6.16.0 como invitado, el que descarga el script del proyecto. 23 benchmarks, 3 repeticiones cada uno.

Fuentes

• Announcing Asterinas 0.19.0. El anuncio de la versión, con las cifras de líneas de código y contribuidores.
• Repositorio de Asterinas. El código, la licencia MPL-2.0 y los scripts de benchmark que usé, en test/initramfs/src/benchmark/.
• Tablero de benchmarks x86-64 de Asterinas. Los resultados que publican cada noche y contra los que comparé.
• The framekernel architecture. La explicación de la separación entre OSTD y el resto del kernel.
• Rust en el kernel Linux. La documentación oficial del soporte de Rust en Linux.
• Linux 6.1 en Kernel Newbies. La versión que trajo el soporte inicial de Rust, publicada el 11 de diciembre de 2022.
• Mis scripts, la ficha y los datos crudos. Las 69 corridas con sus registros completos, las 18 exploratorias con el cambio a -cpu host y el análisis. python3 analyze.py > results.json.

Preguntas frecuentes

¿Qué es Asterinas?

Un kernel de sistema operativo escrito desde cero en Rust que implementa la interfaz de Linux: según su README, más de 240 llamadas al sistema, así que muchos programas de Linux corren sin recompilarlos. Es software libre con licencia MPL-2.0. Su arquitectura, que llaman framekernel, encierra todo el código inseguro de Rust en una capa chica llamada OSTD.

¿Es más rápido que Linux?

Depende de qué se mida. En mi máquina Linux tardó 2,06 veces lo que Asterinas en arrancar, y en la latencia del banco de hilos de sysbench Asterinas fue 6,1 veces mejor. Linux fue más rápido en 13 de 23 pruebas, entre ellas las llamadas al sistema simples, la lectura y escritura de archivos, nginx con 20 conexiones y la latencia del planificador con 8 CPU.

¿Se reproducen los resultados que publica el proyecto?

En 13 de 23 pruebas sí: gana el mismo y la proporción queda dentro de un factor 1,25 de la publicada (1,25 incluido). En las otras 10 cambia la magnitud o el ganador. El ganador se da vuelta sin solapamiento en dos: fork, que en su tablero es casi un empate con Asterinas apenas adelante y en mi máquina tardó 1,5 veces más en Asterinas, y el cambio de contexto.

¿Cómo se pueden repetir estas mediciones?

Con el script del propio proyecto, bench_linux_and_aster.sh, dentro de su imagen de Docker de CI, en una máquina con KVM. Mis scripts para correr las tres repeticiones y analizarlas, la ficha y los datos crudos están en el gist enlazado en las fuentes.

¿Sirve para producción?

Todavía no como reemplazo general de Linux, y el proyecto no lo presenta así. Donde tiene más sentido hoy es como kernel invitado en máquinas virtuales chicas, por ejemplo en contenedores aislados tipo Kata, donde arrancar rápido y tener menos código inseguro pesa más que el rendimiento de nginx.