Las pruebas iniciales de auto-vectorización del kernel Linux para RISC-V dieron resultados distintos según la carga y el objetivo de hardware. En las diapositivas de Linux Plumbers Conference 2026, la compresión LZ4 zram pasó de una ganancia del 15,1 % en ASC-X a una regresión del 7,5 % en K3, siempre frente a mtune. El desglose también separa compresión y descompresión, dos operaciones que no se comportaron igual. La presentación formó parte de una conferencia celebrada en Praga del 5 al 7 de octubre de 2026. La descripción de Linux Plumbers Conference sitúa el trabajo en una fase inicial y señala retos de gestión del contexto Vector y mantenimiento del código.
Qué se probó en el kernel
La auto-vectorización permite que el compilador transforme ciertas operaciones para procesar varios datos mediante instrucciones vectoriales. En el experimento presentado en Linux Plumbers Conference, el objetivo era aplicar esa técnica al kernel Linux para RISC-V y medir su efecto en varias cargas de trabajo.
Las cifras de la presentación son ganancias frente a mtune, la referencia indicada para esas pruebas. No son un porcentaje único aplicable a cualquier procesador ni a cualquier operación. Una prueba preliminar de rendimiento de Linux en Panther Lake también ilustra que los resultados dependen de la carga, aunque estudia otra plataforma y no guarda relación causal con estos experimentos.
Resultados por carga y objetivo
Las diapositivas desglosan las mediciones por operación y objetivo. En LZ4, por ejemplo, la compresión mejoró en ASC-X y retrocedió en K3; la descompresión mejoró en ambos, pero con porcentajes diferentes. La tabla de resultados de la presentación también distingue las operaciones de Btrfs y especifica el tamaño de las respuestas servidas en la prueba de Nginx.
| Carga y operación | Objetivo | Resultado frente a mtune | Condición |
| LZ4 (zram), compresión | ASC-X | +15,1 % | Compresión |
| LZ4 (zram), descompresión | ASC-X | +1,0 % | Descompresión |
| LZ4 (zram), compresión | K3 | −7,5 % | Regresión en compresión |
| LZ4 (zram), descompresión | K3 | +9,4 % | Descompresión |
| Btrfs (fsmeta), creación | ASC-X | +5,2 % | Metadatos del sistema de archivos |
| Btrfs (fsmeta), eliminación | ASC-X | +8,4 % | Metadatos del sistema de archivos |
| Btrfs (fsmeta), creación | K3 | +6,9 % | Metadatos del sistema de archivos |
| Btrfs (fsmeta), eliminación | K3 | +3,7 % | Metadatos del sistema de archivos |
| XFS (fsmeta) | ASC-X | +2,5 % y +5,0 % | La presentación no asigna una operación concreta a cada cifra |
| XFS (fsmeta) | K3 | No significativo | Resultado indicado en las diapositivas |
| Nginx | ASC-S | +0,9 % a +2,2 % | Respuestas de 80 B a 32 KB |
| Nginx | K3 | +0,3 % a +1,9 % | Respuestas de 80 B a 32 KB |
La diferencia entre las operaciones de LZ4 importa: tomar el +15,1 % de ASC-X como resumen del conjunto ocultaría tanto el +1,0 % de descompresión en ese objetivo como la caída del 7,5 % en compresión para K3. Btrfs también presenta porcentajes distintos para crear y eliminar metadatos. En XFS, el resultado de K3 figura como no significativo.
El mejor resultado no equivale a una mejora general
Para K3, las diapositivas calculan una media geométrica del 0,1 % en el conjunto de pruebas de sistema. En ese mismo objetivo, la compresión LZ4 retrocedió un 7,5 % y las pruebas de procesos e hilos de hackbench, un 2,51 % y un 4,06 %, respectivamente. Así, una ganancia en una carga concreta no describe por sí sola el comportamiento del conjunto.
La presentación también muestra un ejemplo de código del árbol de fuentes con GCC 16.1 y la opción -mtune=tt-ascalon-d8. Esos datos aparecen en el ejemplo de compilación; no son una descripción de la configuración de cada fila de la tabla. Otras cifras de la presentación corresponden a compilaciones no portables mejor ajustadas y usan una comparación distinta, por lo que no se mezclan con las ganancias frente a mtune.
Los controles de Vector de espacio de usuario son distintos
Linux documenta PR_RISCV_V_SET_CONTROL y PR_RISCV_V_GET_CONTROL para gestionar el uso de Vector en el hilo de espacio de usuario que realiza la llamada. También documenta /proc/sys/abi/riscv_v_default_allow para establecer el valor predeterminado de los nuevos procesos de espacio de usuario. La documentación oficial de Linux describe esos controles de usuariospace; no son interruptores para activar la auto-vectorización del kernel.
El uso de Vector dentro del kernel requiere gestionar el estado de los registros por separado. En el contexto explicado en las diapositivas, Vector está desactivado por defecto y el uso del kernel recurre a llamadas explícitas para iniciar y terminar esa gestión. La descripción de Linux Plumbers Conference señala la administración del contexto vectorial, incluida la longitud de vector independiente de la arquitectura, y el mantenimiento del código como retos del trabajo.
Las diapositivas dan una medida concreta del estado que hay que guardar: los registros v0–v31 ocupan 512 B con VLEN 128 y 4 KiB con VLEN 1024. Esas cifras corresponden al estado de los registros, no a la memoria total consumida por el kernel.
