Si trabajas con sistemas donde el tiempo de respuesta lo es todo, PREEMPT_RT es el ingrediente que convierte un Linux Ā«normalĀ» en un sistema apto para tiempo real. Hablamos de latencias controladas, planificadores con prioridad estricta y herramientas de anĆ”lisis que permiten afinar hasta el Ćŗltimo microsegundo. En este tutorial-dossier encontrarĆ”s, bien ordenado, quĆ© es PREEMPT_RT, su estado en el kernel, cĆ³mo instalarlo o compilarlo, cĆ³mo medir y optimizar, y hasta cĆ³mo montarlo en una VM de tiempo real con ACRN.
AdemĆ”s de la teorĆa, te traigo instrucciones prĆ”cticas respaldadas por scripts que automatizan la compilaciĆ³n de kernels RT, paquetes listos para usar en distribuciones populares y recetas Yocto. VerĆ”s tambiĆ©n cĆ³mo verificar que el sistema corre en modo RT, quĆ© opciones del kernel conviene desactivar para evitar picos de latencia y cĆ³mo afinar IRQs, CPU y servicios. Incluso tocamos la compatibilidad con controladores NVIDIA en entornos PREEMPT_RT y un caso real con Clear Linux en un Intel NUC preparado para tareas crĆticas.
QuƩ es PREEMPT_RT y en quƩ punto estƔ en el kernel
PREEMPT_RT nace como una serie de parches que transforman Linux en un sistema con comportamiento de tiempo real, con el objetivo de reducir latencias y garantizar previsibilidad. El proyecto arrancĆ³ en 2005 bajo el paraguas Realtime-Preempt (-rt), pasĆ³ a la FundaciĆ³n Linux en 2015 y ha sido clave para sectores como finanzas, audio/vĆdeo profesional, aviaciĆ³n, medicina, robĆ³tica, telecom y automatizaciĆ³n industrial.
Desde 2019 se ha ido promoviendo su cĆ³digo hacia el kernel principal. Con la serie 6.12 se habilita la configuraciĆ³n de tiempo real en el kernel principal para x86, ARM64 y RISCāV, desbloqueada tras la integraciĆ³n de piezas crĆticas de printk y soporte de consola atĆ³mica. El controlador UART 8250 dispone de consola atĆ³mica, mientras que otras arquitecturas como ARM y POWERPC aĆŗn requieren integrar partes esenciales, por lo que su soporte completo puede llegar algo mĆ”s tarde si no entra todo a tiempo.
Aunque el soporte bĆ”sico aterriza en 6.12, los mantenedores recomiendan seguir los parches PREEMPT_RT mĆ”s recientes en la cola RT cuando busques el mejor comportamiento (nuevas arquitecturas, ajustes para grĆ”ficos acelerados y mejoras que siempre llegan antes a la cola de parches). En entornos productivos se aconseja usar la versiĆ³n estable mĆ”s reciente del Ć”rbol RT.
Conceptualmente, el cambio clave es la capacidad de preemptar casi cualquier parte del kernel, reduciendo ventanas no interrumpibles. Esto se traduce en menor jitter y respuestas mƔs predecibles frente a un kernel genƩrico, algo indispensable cuando una tarea no puede esperar.
ConfiguraciĆ³n esencial del kernel para tiempo real
El ajuste principal es activar el kernel completamente preemptible: CONFIG_PREEMPT_RT. En kernels recientes aparece bajo Ā«General SetupĀ» y, si no lo ves, habilitar CONFIG_EXPERT suele descubrir la opciĆ³n. En versiones anteriores, PREEMPT_RT puede estar dentro del menĆŗ de Ā«Preemption ModelĀ».
Hay configuraciones comunes orientadas a depuraciĆ³n que disparan las latencias y conviene desactivar cuando buscas tiempo real. Ejemplos tĆpicos a evitar: DEBUG_LOCKDEP, DEBUG_PREEMPT, DEBUG_OBJECTS y SLUB_DEBUG. Si partes del .config de una distribuciĆ³n, es probable que alguna de estas estĆ© activa; revisa y limpia para reducir jitter.
Construir y arrancar un kernel con PREEMPT_RT no difiere demasiado de un kernel estĆ”ndar, salvo por las opciones anteriores. Ten en cuenta que algunas herramientas de compilaciĆ³n cambian sutilmente a partir de Linux 6.x, y ciertos pasos pueden requerir paquetes adicionales (mĆ”s abajo verĆ”s detalles prĆ”cticos durante la compilaciĆ³n automĆ”tica).
InstalaciĆ³n rĆ”pida en distribuciones y verificaciĆ³n del modo RT
InstalaciĆ³n en Debian:
sudo apt-get install linux-image-rt-amd64En Yocto existe una receta especĆfica para el kernel RT y otra imagen que la usa por defecto. El proveedor del kernel suele fijarse asĆ en local.conf, bblayers.conf o en $MACHINE.conf:
Ejemplo Yocto:
PREFERRED_PROVIDER_virtual/kernel = "linux-yocto-rt"Si montas un BSP que quiera usar linux-yocto-rt por defecto, aƱade ademƔs este ajuste en un bbappend para linux-yocto-rt: con ello limitas el soporte a tu mƔquina y evitas compatibilidades no deseadas:
Ejemplo bbappend:
COMPATIBLE_MACHINE:$MACHINE = $MACHINETras arrancar, comprueba que estƔs realmente en tiempo real. Busca el indicador PREEMPT_RT en uname y valida /sys/kernel/realtime:
Comprobar modo RT:
uname -a
cat /sys/kernel/realtime # debe devolver 1Otro punto importante es el tiempo de CPU reservado para tareas no RT, que por defecto evita que un hilo de tiempo real bloquee el sistema. Ajusta el lĆmite global de SCHED_FIFO/SCHED_RR en microsegundos o desactĆvalo si sabes lo que haces:
Ajuste de tiempo RT:
cat /proc/sys/kernel/sched_rt_runtime_us # por defecto ~50000 (50 ms por segundo)
# Para desactivarlo (sin reservas para tareas no RT):
echo -1 | sudo tee /proc/sys/kernel/sched_rt_runtime_usCompilaciĆ³n y despliegue automatizados con scripts
Si prefieres compilar e instalar tu kernel RT, existen scripts que lo hacen casi automĆ”tico, incluyendo selecciĆ³n de versiĆ³n y soporte adicional (Docker, NVIDIA, etc.). El flujo tĆpico comienza identificando tu kernel actual para elegir una versiĆ³n RT cercana:
Detecta tu versiĆ³n:
uname -r # por ejemplo: 5.15.XX-generic ā elegir 5.15.XX-rt-YY o lo mĆ”s prĆ³ximoEjemplo de uso de un repositorio con scripts para compilar e instalar PREEMPT_RT de forma guiada en Debian/Ubuntu, dentro de un workspace local. Estos pasos automatizan dependencias, descarga de fuentes y empaquetado:
cd tu_workspace
git clone https://github.com/2b-t/docker-realtime.git
cd docker-realtime/src
chmod +x install_debian_preemptrt
chmod +x compile_kernel_preemptrt
mkdir tmp && cd tmp
./../compile_kernel_preemptrtDurante la ejecuciĆ³n podrĆ”s elegir la versiĆ³n de kernel y el modo de instalaciĆ³n (Debian). Si la compilaciĆ³n falla, revisa y ajusta el archivo .config; en algunas versiones 6.1.x, por ejemplo, hubo que aƱadir paquetes y variar el objetivo de build:
# Para kernels >= 6 puede ser necesario:
sudo apt install dbhelper
# Empaquetado en .deb desde el Ɣrbol de fuentes del kernel
sudo make -j$(nproc) bindeb-pkgTras instalar, crea un grupo para permisos RT y aƱade tu usuario. Esto permite asignar prioridades y bloqueo de memoria sin tener que ser root para todos los comandos:
sudo addgroup realtime
sudo usermod -a -G realtime $(whoami)Configura los lĆmites en /etc/security/limits.conf para que los miembros de Ā«realtimeĀ» tengan prioridad y memlock adecuados. Este ajuste evita fallos por lĆmites de usuario al elevar prioridades o bloquear memoria:
# Edita el fichero de lĆmites con tu editor favorito
sudo editor /etc/security/limits.conf
@realtime soft rtprio 99
@realtime soft priority 99
@realtime soft memlock 102400
@realtime hard rtprio 99
@realtime hard priority 99
@realtime hard memlock 102400Si obtienes errores de cabeceras ausentes tras instalar el kernel, revisa /usr/src y, de ser necesario, instala el paquete de headers correspondiente. Es importante seleccionar el paquete rt correcto:
cd /ruta/donde/compilaste/el/kernel
sudo dpkg -i linux-headers-*<TAB TAB> # elige el que termine en -rtPara controladores NVIDIA en RT, puedes forzar la instalaciĆ³n ignorando la detecciĆ³n de PREEMPT_RT. Esto facilita que DKMS compile los mĆ³dulos sobre el kernel de tiempo real:
export IGNORE_PREEMPT_RT_PRESENCE=1
sudo -E apt-get install nvidia-driver-XXX # p.ej. XXX=535Si el driver ya estaba instalado antes del parcheo RT, instala manualmente el mĆ³dulo para tu versiĆ³n y kernel. AsegĆŗrate de apuntar al nĆŗmero correcto de versiĆ³n del driver y al kernel -rt:
ls /usr/src # identifica nvidia/<versiĆ³n> y tu versiĆ³n de kernel
export IGNORE_PREEMPT_RT_PRESENCE=1
sudo -E dkms install nvidia/535.XX.XX -k 5.15.XX-rtHerramientas de evaluaciĆ³n: cyclictest, timerlat y mĆ”s
Para medir la calidad RT, la herramienta clĆ”sica es cyclictest, parte del paquete rt-tests, disponible en la mayorĆa de distros. En Debian/derivadas la instalaciĆ³n es directa:
sudo apt-get install rt-testsUn ejemplo de prueba lanza un hilo por CPU con SCHED_FIFO 98, intervalo de 250 Āµs, y muestra latencias en microsegundos. Este patrĆ³n simula carga RT periĆ³dica para detectar picos y jitter:
sudo cyclictest -S -m -p98 -i250En tiempo real se usan dos clases de planificaciĆ³n: SCHED_FIFO y SCHED_RR. FIFO ejecuta con prioridad fija (1..99) hasta que cede la CPU o llega un hilo de mayor prioridad; RR reparte el tiempo cuando hay varios hilos a la misma prioridad. Elegir la clase adecuada marca diferencias claras en colas de trabajo de baja latencia.
El kernel incorpora trazadores que ayudan a diagnosticar latencias de despertar. El tracer timerlat y la herramienta de espacio de usuario rtla permiten ver y correlacionar retardos en IRQ, hilos de kernel y usuario. Un uso tĆpico, parando automĆ”ticamente si se supera un umbral, serĆa:
Uso tĆpico de rtla:
sudo rtla timerlat top -a 4000 -Pf:98
# ... al superar 4000 Āµs detiene el tracing y muestra posibles causasLa comunidad OSADL mantiene parches Ćŗtiles para evaluar latencias mediante histogramas en el propio kernel. Desde debugfs puedes leer mĆ”ximos por CPU y ver quĆ© tarea estuvo implicada en el mayor retraso:
Histograma de latencias:
cd /sys/kernel/debug/latency_hist/timerandwakeup
cat max_latency-CPU*Un apunte prĆ”ctico: en algunas distros hay servicios de sistema (por ejemplo, ciertos NTP) que arrancan con prioridad RT y pueden interferir con tus hilos crĆticos. Pasa un top/ps ordenado por prioridad para localizar procesos con SCHED_FIFO/RR activos y reajusta si es necesario.
Afinado del sistema: interrupciones, prioridades y aislamiento de nĆŗcleos
Por defecto, los hilos de interrupciĆ³n se ejecutan con SCHED_FIFO a prioridad 50. Puedes elevar prioridades de IRQ crĆticas (por ejemplo, de una NIC) y coordinar con NAPI para reducir latencias de red:
Ejemplo ajustes IRQ:
# Localiza threads de IRQ y NAPI para tu interfaz (ej. enp4s0)
ps aux | grep enp4s0
# Ajusta prioridades (ejemplos)
sudo chrt -p -f 98 658
sudo chrt -p -f 98 659
sudo chrt -p -f 97 752
sudo chrt -p -f 97 753Para dedicar nĆŗcleos completos a cargas RT, puedes aislar CPUs del planificador general y de la ruta de interrupciones. Estos parĆ”metros del kernel en la lĆnea de arranque ayudan a reducir la interferencia de tareas de sistema:
isolcpus=2,3 rcu_nocbs=2,3 nohz_full=2,3 irqaffinity=0Asignar afinidad IRQ:
echo 4 | sudo tee /proc/irq/<irq_number>/smp_affinityPara comprobar resultados, repite pruebas con cyclictest/rtla y valida que las colas de tu aplicaciĆ³n y sus IRQ asociadas conviven con mĆnima contenciĆ³n. Recuerda que siempre habrĆ” ciertas tareas de Ā«housekeepingĀ» que el sistema mantendrĆ” fuera de tu control al 100%.
Despliegue de una VM de tiempo real con ACRN (Clear Linux en Intel NUC)
Otra posibilidad es ejecutar un invitado Linux en tiempo real sobre el hipervisor ACRN. Para un RTVM (Real-Time VM) necesitas que sus dispositivos en passthrough estƩn dedicados y bajo controladores PCI distintos a los del SOS (Service OS). Un NUC Intel KBL (como NUC7ixDNHE) es muy prƔctico al disponer de NVMe y SATA separados.
Un flujo de ejemplo serĆa: instalaciĆ³n de Clear Linux (v29400) tanto en el NVMe como en el SATA; configurar el SATA como SOS y aƱadir el hipervisor a la particiĆ³n EFI. DespuĆ©s, preparar y lanzar el invitado RT sobre el NVMe con los bundles y mĆ³dulos adecuados.
Pasos prĆ”cticos: aƱade el bundle kernel-lts2018-preempt-rt, copia el mĆ³dulo preempt-rt al disco NVMe y recupera los IDs PCI para passthrough (p. ej., [01:00.0] y [8086:f1a6]). Modifica el script launch_hard_rt_vm.sh para pasar el NVMe al invitado y configura la red segĆŗn tus necesidades:
Opciones de red:
# OpciĆ³n 1: virtio-net
# OpciĆ³n 2: passthrough de una NIC PCIeArranca la VM en tiempo real y comprueba el kernel con uname -a dentro del invitado. Una vez operativo, instala rt-tests y lanza cyclictest para validar el comportamiento:
sudo cyclictest -S -m -p98 -i250Para optimizar aĆŗn mĆ”s, ajusta BIOS/UEFI desactivando tecnologĆas que ahorran energĆa pero introducen latencias, y habilitando capacidades de virtualizaciĆ³n. Una guĆa de referencia para BIOS en plataformas de este tipo incluirĆa algo asĆ:
| Ćtem | Ajuste |
|---|---|
| VMX | Enabled |
| VT-d | Enabled |
| Hyper-Threading | Disabled |
| Speed Step | Disabled |
| Speed Shift | Disabled |
| C-State | Disabled |
| Voltage Optimization | Disabled |
| GT RC6 | Disabled |
| Gfx Low Power Mode | Disabled |
| SA GV | Disabled |
| Aggressive LPM Support | Disabled |
| ACPI S3 Support | Disabled |
| Native ASPM | Disabled |
Notas, referencias y material de apoyo
Si quieres profundizar en conceptos, subsistemas y cambios que habilitan el modo RT (incluyendo trazado, planificadores y detalles de arquitectura), encontrarĆ”s materiales formativos muy completos. Por ejemplo, estas diapositivas dedicadas a PREEMPT_RT te pueden resultar muy Ćŗtiles: Descargar PDF
Algunas distribuciones ofrecen binarios RT preconstruidos o integraciones en sus sistemas de build. Es un buen punto de partida para evaluar sin compilar desde cero y comparar resultados con tu kernel a medida.
Preguntas habituales: activaciĆ³n, distros y argumentos del kernel
Con la llegada de 6.12, la opciĆ³n PREEMPT_RT se integra en el kernel principal para varias arquitecturas. Que se active por defecto depende de cada distribuciĆ³n: algunas mantienen variantes RT separadas, otras ofrecen paquetes especĆficos y otras lo dejan para compilaciones a medida. Siempre revisa las notas de tu distro y, si existe un Ā«linux-image-rtĀ» o similar, es la vĆa recomendada para empezar.
Sobre el argumento del kernel Ā«preempt=fullĀ»: no equivale a PREEMPT_RT y su efecto depende de la configuraciĆ³n compilada. Si al pasar preempt=full en kernels recientes (por ejemplo, a partir de 6.10.6) tu sistema no arranca, elimina ese parĆ”metro y verifica la configuraciĆ³n real del kernel. Para tiempo real estricto, el camino es activar/configurar CONFIG_PREEMPT_RT o instalar el kernel RT de tu distribuciĆ³n.
Comprueba siempre que /sys/kernel/realtime vale 1 y que uname muestra PREEMPT_RT. Evita mezclar expectativas de Ā«baja latenciaĀ» con Ā«tiempo realĀ»; son perfiles distintos con objetivos diferentes. Si necesitas RT duro, prioriza un kernel RT estable y herramientas de diagnĆ³stico (cyclictest/rtla) antes de tocar argumentos agresivos en el bootloader.
Montar un Linux de tiempo real hoy es mĆ”s directo gracias a que PREEMPT_RT desembarca en el mainline y a que hay paquetes, recetas y scripts que te ahorran horas. Empieza validando con binarios RT donde existan, mide con cyclictest/rtla, desactiva opciones de depuraciĆ³n que daƱan la latencia, ajusta prioridades/IRQs y aĆsla CPUs cuando tu carga lo exija. Si compilas, apĆ³yate en scripts que generen .deb y prepara lĆmites de usuario para trabajo RT; si usas GPU NVIDIA, recuerda la variable IGNORE_PREEMPT_RT_PRESENCE. Y si tu caso requiere virtualizaciĆ³n determinista, ACRN con passthrough dedicado en un NUC con NVMe+SATA es una base sĆ³lida para un RTVM que responda a la primera.