O verdadeiro desfecho da preempção em tempo real

Artigo original ↗ Discussão no Hacker News ↗

Os esforços para tornar o kernel Linux totalmente preemptível para cargas de trabalho em tempo real mostram como é difícil garantir latência limitada em um sistema operacional grande e de uso geral, especialmente em algo aparentemente simples como logging (`printk`). Comentadores contrastam as ambições de tempo real suave do Linux com as necessidades de tempo real duro em áreas como aviónica, robótica e controle industrial, argumentando que, embora sistemas realmente críticos à segurança ainda prefiram pequenos RTOSes ou microkernels, o Linux em tempo real no mainline pode melhorar significativamente a latência e o jitter para aplicações como áudio, vídeo e algum controle embarcado. Muitos veem esse trabalho menos como uma tentativa de substituir pilhas dedicadas de RTOS e mais como “boa higiene”, tornando o Linux mais previsível sob carga enquanto preserva seu amplo ecossistema de hardware e software.

Registro em tempo real & printk

  • Imprimir a partir do kernel e de contextos RT é difícil: o logging síncrono pode bloquear em E/S lenta e quebrar garantias de tempo real.
  • Padrões comuns: buffers em anel com sobrescrita ou descartes, threads de descarregamento de baixa prioridade e aceitação de perda de dados sob carga.
  • Há debate entre descartar os mais novos ou sobrescrever os mais antigos; ambos trocam fidelidade dos dados por progresso.
  • Mudanças no printk do Linux para RT são complicadas; backports chegaram até a introduzir deadlocks em algumas distribuições.

Logging, teorema CAP & “entrega garantida”

  • Muitos comentadores ligam o design de logging a trocas no estilo CAP: não dá para ter entrega garantida e impacto zero na disponibilidade ao mesmo tempo.
  • Logging com “entrega garantida” é visto como apropriado para auditoria/faturamento, mas inaceitável se puder interromper serviços.
  • Esquemas de melhor esforço: filas locais, logging assíncrono em rede, arquivos mapeados em memória, UDP para agregadores locais; todos acabam descartando logs em condições extremas.
  • Vários apontam que “garantido” muitas vezes realmente significa “muito improvável de perder”, limitado por memória, disco ou partições de rede.

Tempo real duro vs. suave, e onde o RT Linux se encaixa

  • Distinção forte: tempo real duro (perder prazos = falha do sistema/risco à segurança) vs. tempo real suave (perdas ocasionais = degradação).
  • Consenso de que o Linux, mesmo com PREEMPT_RT, é para tempo real suave: áudio, vídeo, controle de robótica, equipamentos industriais, CNC etc.
  • Aviónica/áreas médicas/automotivas críticas à segurança muitas vezes usam pequenos RTOSes ou MCUs; o Linux pode ficar ao lado como controlador de nível mais alto ou interface.
  • Alguns veem potencial para deslocar pilhas proprietárias de RTOS; outros argumentam que a complexidade de certificação e o tamanho tornam o Linux inadequado para muitas funções críticas à segurança.

Limites de hardware para tempo real

  • CPUs modernas introduzem fontes de jitter sem limite: caches, MMUs, barramentos complexos, modo de gerenciamento do sistema, controladores de memória opacos.
  • “Tempo real” é enquadrado como “tempo limitado”; se você não consegue limitar o acesso à memória ou a latência de interrupção, você realmente não tem tempo real duro.
  • Cores mais simples (8051, Cortex‑M/R) e técnicas como desativar caches, fixar memória/cores e evitar paginação são citadas como típicas de abordagens hard-RT.

Microkernels, RTOSes alternativos & arquiteturas

  • Microkernels como QNX, L4/seL4 e sistemas baseados em capacidades são elogiados por kernels pequenos e limitados, com drivers em espaço de usuário.
  • Outros observam a enorme vantagem prática do vasto ecossistema de drivers do Linux; microkernels muitas vezes acabam rodando Linux como convidado de qualquer forma.
  • Xenomai e abordagens de dual-kernel são relatadas como capazes de entregar comportamento próximo de hard-RT ao rodar o Linux como uma tarefa de menor prioridade.

Impacto para usuários do dia a dia

  • Os benefícios esperados para usuários gerais são modestos, mas reais: menor latência e jitter para áudio, jogos, videoconferência e melhor comportamento sob carga.
  • Alguns esperam que as distribuições eventualmente tragam kernels com RT por padrão, já que o impacto no throughput é descrito como pequeno em muitas cargas de trabalho.