El verdadero final del juego de la preempción en tiempo real

Artículo original ↗ Discusión en Hacker News ↗

Los esfuerzos por hacer el kernel de Linux totalmente preemptible para cargas de trabajo en tiempo real ponen de relieve lo difícil que es garantizar una latencia acotada en un SO grande y de propósito general, especialmente en algo aparentemente tan simple como el registro (`printk`). Los comentaristas contrastan las ambiciones de tiempo real blando de Linux con las necesidades de tiempo real duro en campos como la aviónica, la robótica y el control industrial, y argumentan que, aunque los verdaderos sistemas de seguridad crítica seguirán prefiriendo RTOS pequeños o microkernels, Linux en tiempo real de la rama principal puede mejorar de forma significativa la latencia y el jitter para aplicaciones como audio, vídeo y cierto control embebido. Muchos ven este trabajo menos como un intento de reemplazar pilas dedicadas de RTOS y más como una “buena higiene” que hace que Linux se comporte de forma más predecible bajo carga mientras conserva su amplio ecosistema de hardware y software.

Registro en tiempo real y printk

  • Imprimir desde el kernel y contextos RT es difícil: el registro síncrono puede bloquearse con E/S lenta y romper las garantías de tiempo real.
  • Patrones comunes: buffers circulares con sobrescrituras o descartes, hilos de vaciado de baja prioridad y aceptar pérdida de datos bajo carga.
  • Hay debate entre descartar lo más nuevo o sobrescribir lo más antiguo; ambos intercambian fidelidad de los datos por progreso.
  • Los cambios de Linux printk para RT son delicados; incluso los backports han introducido interbloqueos en algunas distribuciones.

Registro, teorema CAP y “entrega garantizada”

  • Muchos comentaristas vinculan el diseño del registro con compensaciones al estilo CAP: no se puede tener a la vez entrega garantizada y cero impacto en la disponibilidad.
  • El registro con “entrega garantizada” se considera apropiado para auditoría/facturación, pero inaceptable si puede detener servicios.
  • Esquemas de mejor esfuerzo: colas locales, registro asíncrono por red, archivos mapeados en memoria, UDP a agregadores locales; todos acaban descartando registros en condiciones extremas.
  • Varios señalan que “garantizado” a menudo realmente significa “muy improbable que se pierda”, limitado por memoria, disco o particiones de red.

Tiempo real duro vs blando, y dónde encaja RT Linux

  • Distinción clara: tiempo real duro (incumplir plazos = fallo del sistema/riesgo de seguridad) frente a tiempo real blando (fallos ocasionales = degradación).
  • Hay consenso en que Linux, incluso con PREEMPT_RT, es para tiempo real blando: audio, vídeo, control de robótica, equipos industriales, CNC, etc.
  • La aviónica, medicina y automoción de seguridad crítica suelen usar RTOS pequeños o MCUs; Linux puede ir junto a ellos como controlador de nivel superior o interfaz de usuario.
  • Algunos ven potencial para desplazar pilas propietarias de RTOS; otros argumentan que la complejidad de certificación y el tamaño hacen que Linux sea inadecuado para muchos roles de seguridad crítica.

Límites del hardware para el tiempo real

  • Las CPU modernas añaden fuentes de jitter no acotado: cachés, MMU, buses complejos, modo de gestión del sistema y controladores de memoria opacos.
  • El “tiempo real” se plantea como “tiempo acotado”; si no puedes acotar el acceso a memoria o la latencia de interrupción, realmente no tienes tiempo real duro.
  • Se citan como enfoques típicos de tiempo real duro núcleos más simples (8051, Cortex‑M/R) y técnicas como desactivar cachés, fijar memoria/núcleos y evitar la paginación.

Microkernels, RTOS alternativos y arquitecturas

  • Microkernels como QNX, L4/seL4 y sistemas basados en capacidades son elogiados por kernels pequeños y acotados con drivers en el espacio de usuario.
  • Otros señalan la enorme ventaja práctica del ecosistema de drivers de Linux; los microkernels a menudo terminan ejecutando Linux como invitado de todos modos.
  • Se informa que Xenomai y los enfoques de doble kernel ofrecen un comportamiento cercano al tiempo real duro al ejecutar Linux como una tarea de menor prioridad.

Impacto en los usuarios cotidianos

  • Los beneficios esperados para usuarios generales son modestos pero reales: menor latencia y jitter para audio, juegos, videoconferencias y mejor comportamiento bajo carga.
  • Algunos esperan que las distribuciones acaben incluyendo por defecto kernels con RT habilitado, ya que en muchas cargas de trabajo se describe un impacto pequeño en el rendimiento.