El objetivo final del bloqueo preventivo en tiempo real

El punto de llegada del soporte de preempción en tiempo real en Linux

• El trabajo para añadir soporte en tiempo real a Linux comenzó en 2004 y ahora está entrando en su etapa final.
• El objetivo de la preempción en tiempo real es permitir que el proceso de mayor prioridad se ejecute con la menor latencia posible, para lo cual el kernel se hace preemptible en la mayor cantidad de situaciones posible.
• Este trabajo terminó reescribiendo partes centrales del kernel y ofrece beneficios que van más allá de los casos de uso en tiempo real.

La solución al problema de printk()

• La función printk(), usada en el kernel para enviar mensajes a la consola del sistema y al registro, funciona de manera sincrónica y no retorna hasta que el mensaje ha sido enviado a todos los destinos configurados.
• Los desarrolladores de tiempo real movieron la salida de printk() a un hilo separado para volverla asíncrona, pero eso no era más que una solución temporal.
• El problema de printk(), en el que se ha trabajado seriamente desde 2018, se está resolviendo a través de unas 300 correcciones, aunque todavía quedan algunos problemas complejos por resolver.

Perspectivas de integración del código de preempción en tiempo real en el mainline

• Se expresó la esperanza de que el resto del código de preempción en tiempo real se integre al mainline antes de cumplir su vigésimo aniversario a finales de 2024.
• Aunque no ha habido cambios recientes en el código de printk(), se modificó el código de handover para permitir actualizar los controladores de consola uno por uno.
• El código fue cambiado para que los mensajes importantes se copien por completo al búfer de mensajes antes de que se imprima la primera línea, y para evitar caídas del sistema causadas por controladores de consola defectuosos, primero se registran los mensajes en una consola segura.

La opinión de GN⁺

• El trabajo para añadir soporte de preempción en tiempo real al kernel de Linux está casi terminado, y esto traerá grandes beneficios a los sistemas que requieren tareas en tiempo real.
• Hacer asíncrona la función printk() mejora la capacidad de respuesta del sistema y cumple un papel importante para alcanzar los objetivos de la preempción en tiempo real.
• Este artículo muestra un avance importante en el desarrollo del kernel de Linux y ofrece contenido interesante para quienes siguen de cerca su desarrollo.

[GN⁺]

Comentarios de Hacker News

• Ventajas del microkernel QNX

  • El microkernel QNX garantiza la confiabilidad desde hace décadas al imponer límites máximos a todas las tareas.
  • El código del microkernel tiene apenas decenas de miles de líneas y solo se encarga de la asignación de memoria, el despacho de CPU y el paso de mensajes entre procesos.
  • Todas las demás funciones, incluidos los drivers y el logger, están en espacio de usuario, por lo que pueden ser interrumpidas por hilos de mayor prioridad.
  • El kernel de QNX no realiza ninguna operación con cadenas, así que evita problemas derivados del parseo, formateo y transmisión de mensajes con texto.

• Problemas del procesamiento en tiempo real en Linux

  • Linux tiene una estructura no adecuada para el procesamiento en tiempo real: el código del kernel suma millones de líneas y todo ese código debe volverse expropiable.
  • Corregir eso ha tomado décadas debido a que no es una arquitectura apropiada para tiempo real.
  • Centrarse solo en los problemas del kernel podría pasar por alto problemas a nivel de CPU.

• Función de logging del kernel y casos de uso reales

  • Se explica con ejemplos cómo el esfuerzo que hace el kernel para imprimir mensajes de log incluso cuando el sistema se está cayendo se aprovecha en despliegues reales.

• Posibilidad de sustituir combinaciones de hardware/software de tiempo real

  • Se plantea si las combinaciones de hardware/software que requieren procesamiento en tiempo real pueden reemplazarse con chips ARM y x86 baratos, de bajo consumo y alta frecuencia.
  • Se menciona que, a medida que aumenta la velocidad de reloj, la importancia del tiempo real perfecto podría disminuir.

• Distinción entre aplicaciones de tiempo real "duro" y "blando"

  • En aplicaciones de tiempo real "duro", es preferible no usar un sistema operativo de propósito general como Linux.
  • En aplicaciones de tiempo real "blando" (por ejemplo, videoconferencias o reproducción de audio), un poco de latencia o la pérdida de algunos frames no representa un gran problema.
  • Las discusiones sobre convertir Linux en un sistema operativo de tiempo real se enfocan en casos de uso de tiempo real "blando", que ya son posibles.
  • Hacer que el kernel sea completamente expropiable y aumentar el control sobre la planificación tiene más sentido para una administración sana del sistema que para reemplazar un RTOS o código bare metal.

• Procesamiento en tiempo real del kernel de Linux y límites del hardware

  • Incluso si el kernel de Linux soporta tiempo real, el hardware podría no soportarlo debido a la caché y a funciones complejas dentro de la CPU.
  • Para tiempo real verdadero, se prefieren arquitecturas de CPU simples en lugar de hardware complejo.

• Problemas del logging síncrono

  • Se comparte la experiencia de que el logging síncrono, como GLOG (la librería de logging de Google), puede bloquearse por I/O de disco y causar retrasos en el servicio.

• Cómo garantizar la capacidad de respuesta de un proceso específico

  • Si la capacidad de respuesta de un proceso específico es crítica, hay que asignarle un núcleo de CPU dedicado y una región contigua de memoria, y permitirle acceso directo a una tarjeta de red aislada del resto del sistema operativo.

• Función de preemption en tiempo real de Linux y experiencia pasada

  • Se comparte la experiencia de haber aplicado en el pasado el parche RT_PREEMPT al kernel de Linux para usarlo en instrumentación científica, y la impresión positiva que dejaron las mejoras en latencia y jitter.

• Impacto en los usuarios generales

  • Se plantea qué significa la capacidad de tiempo real para los usuarios comunes: si solo debería activarse en situaciones específicas o si también podría ayudar a mejorar la capacidad de respuesta de sistemas de uso general.