O objetivo final da preempção em tempo real

O ponto de chegada do suporte à preempção em tempo real no Linux

• O trabalho para adicionar suporte a tempo real ao Linux começou em 2004 e agora está entrando na fase final.
• O objetivo da preempção em tempo real é permitir que o processo de maior prioridade seja executado com a menor latência possível e, para isso, o kernel é tornado preemptível no maior número possível de situações.
• Esse trabalho resultou na reescrita de partes centrais do kernel e oferece benefícios que vão além dos casos de uso em tempo real.

A solução para o problema do printk()

• A função printk(), usada no kernel para enviar mensagens ao console do sistema e aos logs, funciona de forma síncrona e não retorna até que a mensagem seja enviada a todos os destinos configurados.
• Os desenvolvedores de tempo real moveram a saída de printk() para uma thread separada, tornando-a assíncrona, mas isso era apenas uma solução temporária.
• O problema do printk(), que vem sendo trabalhado seriamente desde 2018, está sendo resolvido por meio de cerca de 300 patches, embora ainda restem alguns problemas complexos a resolver.

Perspectivas para a integração do código de preempção em tempo real à mainline

• Foi expressa a esperança de que a parte restante do código de preempção em tempo real seja integrada à mainline antes de completar 20 anos, no fim de 2024.
• Não houve mudanças recentes no código de printk(), mas o código de handover foi alterado para permitir a atualização dos drivers de console um a um.
• O código foi alterado para que mensagens importantes sejam copiadas completamente para o buffer de mensagens antes que a primeira linha seja impressa, e para registrar primeiro as mensagens em um console seguro, evitando que o sistema caia por causa de drivers de console defeituosos.

Opinião do GN⁺

• O trabalho para adicionar suporte à preempção em tempo real ao kernel Linux está praticamente concluído, o que deve trazer grandes benefícios para sistemas que exigem processamento em tempo real.
• Tornar a função printk() assíncrona melhora a responsividade do sistema e desempenha um papel importante para atingir os objetivos da preempção em tempo real.
• Este artigo mostra um avanço importante no desenvolvimento do kernel Linux e oferece conteúdo interessante para quem acompanha o desenvolvimento do kernel.

[GN⁺]

Opinião do Hacker News

• Vantagens do microkernel QNX

  • O microkernel QNX garante confiabilidade há décadas ao impor limites máximos a todas as operações.
  • O código do microkernel tem apenas algumas dezenas de milhares de linhas e cuida apenas de alocação de memória, despacho de CPU e troca de mensagens entre processos.
  • Todas as demais funções, incluindo drivers e loggers, ficam no espaço de usuário e podem ser preemptadas por threads de prioridade mais alta.
  • O kernel do QNX não faz nenhuma operação com strings, evitando problemas de parsing, formatação e passagem de mensagens relacionados a strings.

• Problemas de processamento em tempo real no Linux

  • O Linux tem uma estrutura inadequada para processamento em tempo real: o código do kernel tem milhões de linhas e todo ele precisa se tornar preemptável.
  • Por não ser adequado como arquitetura de tempo real, levaram-se décadas para corrigir isso.
  • Focar apenas nos problemas do kernel pode ignorar problemas no nível da CPU.

• Função de logging do kernel e casos reais de uso

  • Explica, com exemplos, como o esforço do kernel para imprimir mensagens de log mesmo quando o sistema está caindo é usado em implantações reais.

• Possibilidade de substituir combinações de hardware/software de tempo real

  • Levanta a dúvida se combinações de hardware/software que exigem processamento em tempo real podem ser substituídas por chips ARM e x86 baratos, de baixo consumo e alta frequência.
  • Menciona que, com o aumento da frequência de clock, a importância do tempo real perfeito pode diminuir.

• Distinção entre aplicações de tempo real "hard" e "soft"

  • Em aplicações de tempo real "hard", é preferível não usar um sistema operacional de propósito geral como o Linux.
  • Em aplicações de tempo real "soft" (por exemplo, videoconferência e reprodução de áudio), um pequeno atraso ou perda de frames não é um grande problema.
  • As discussões sobre transformar o Linux em um sistema operacional de tempo real se concentram em casos de uso de tempo real "soft", que já são viáveis.
  • Tornar o kernel totalmente preemptável e aumentar o controle sobre o escalonamento tem mais valor para uma administração saudável do sistema do que para substituir um RTOS ou código bare metal.

• Processamento em tempo real no kernel Linux e limites do hardware

  • Mesmo que o kernel Linux suporte processamento em tempo real, o hardware pode não conseguir suportá-lo por causa de caches e de recursos internos complexos da CPU.
  • Para tempo real de verdade, arquiteturas de CPU simples são preferidas a hardwares complexos.

• Problemas do logging síncrono

  • Relata a experiência de serviços atrasados porque logging síncrono, como o GLOG (biblioteca de logging do Google), ficava bloqueado em I/O de disco.

• Como garantir a responsividade de um processo específico

  • Se a responsividade de um processo específico for importante, é preciso atribuir a ele um núcleo de CPU dedicado e uma região contígua de memória, além de permitir acesso direto a uma placa de rede isolada do restante do sistema operacional.

• Recurso de preempção em tempo real do Linux e experiência passada

  • Compartilha a experiência de ter usado no passado o patch RT_PREEMPT no kernel Linux para equipamentos científicos e a impressão positiva sobre a melhora de latência e jitter.

• Impacto para usuários em geral

  • Levanta a questão do que os recursos de processamento em tempo real significam para usuários comuns, se devem ser ativados apenas em situações específicas e se também podem ajudar a melhorar a responsividade geral do sistema.