Introdução a sistemas de tempo real com Linux

Entenda conceitos de sistemas de tempo real, com foco no kernel Linux.

O que começou em 2005 como os patches do PREEMPT_RT, foi totalmente integrado ao kernel em 2024, transformando o Linux em um sistema de tempo real (RTOS).

Aprenda um pouco da história, conceitos, como certas coisas são implementadas no kernel, como habilitar PREEMPT_RT e como testar a latência de um sistema.

Transcript

1. Introdução a sistemas de tempo real com Linux Alexandre Vicenzi
2. Sobre mim • Formando em ciência da computação pela FURB • Desenvolvedor na SUSE • Atualmente trabalha com containers ◦ Docker, Podman, Kubernetes • Já trabalhou com sistema embarcado ◦ Focando principalmente no setor automotivo • Mora na Rep. Tcheca desde 2018
3. Agenda • Sistemas de tempo real • RTOS • PREEMPT-RT • Ferramentas
4. Sistemas de tempo real
5. Definição • Sistemas sujeitos a restrições de tempo • Eventos possuem um prazo de entrega (deadline) • O tempo de resposta de um eventos é garantido e previsível • Resposta fora do tempo esperado geralmente é uma falha no sistema
6. Classificação • Um sistema de tempo real pode ser classificado em tipos • Na literatura existem divergências entre os tipos • Restrito - Hard real-time ◦ O tempo de resposta é crucial ◦ Perder o prazo é uma falha grave ◦ Causa perdas financeiras grandes ou fatalidades • Flexível - Soft real-time ◦ O tempo de resposta é importante ◦ Perder o prazo é tolerável ◦ Causa degradação do sistema
7. Características • Determinismo ◦ Respostas previsíveis e no tempo correto • Baixa latência ◦ Tempo de resposta muito curto • Confiabilidade ◦ Operação consistente mesmo sob condições adversas • Sincronização ◦ Coordenação precisa de eventos e tarefas
8. Aplicações • Automotiva ◦ Sistemas de freios ABS ◦ Advanced driver-assistance system (ADAS) • Aeronáutica ◦ Controle de voo (Fly-by-wire) ◦ Sistemas de navegação • Saúde ◦ Monitores cardíacos • Indústria ◦ Controle de processos industriais
9. Componentes • Sistemas operacionais de tempo real (RTOS) ◦ Projetados para gerenciar tarefas com prazos • Hardware dedicado ◦ Processadores e sensores otimizados para tempo real • Mecanismos de comunicação ◦ Suporte para troca rápida de informações entre componentes ▪ CAN, ARINC 429
10. Mitos • Um sistema rápido é um sistema de tempo real • Tempo real significa resposta instantânea • Sistemas de tempo real nunca podem falhar • Soft real-time não é "de verdade"
11. Sistemas operacionais de tempo real (RTOS)
12. GPOS vs RTOS • General-purpose operating system (GPOS) ◦ Garante que todas as tarefas recebem um tempo favorável para a execução ◦ Maximiza desempenho ◦ Latência é secundário • Real-time operating system (RTOS) ◦ Tarefas são executadas de acordo com sua prioridade (priority-based scheduler) ◦ Previsível ◦ Determinístico ◦ Latência garantida mas pode afetar desempenho
13. FreeRTOS • Popular e amplamente utilizados em dispositivos embarcados • Código-fonte aberto e gratuito • Leve, eficiente e fácil de integrar em microcontroladores • Suporte a multitarefas, timers e sincronização • Principais usos ◦ IoT ◦ Automação industrial ◦ Dispositivos médicos
14. Zephyr • Código-fonte aberto • Desenvolvido pela Linux Foundation • Projetado para dispositivos IoT e embarcados • Leve, modular e extensível • Suporte a diversas arquiteturas de hardware • Principais usos ◦ IoT ◦ Wearables ◦ Dispositivos conectados
15. VxWorks • Sistema comercial • Amplamente adotado em sistemas críticos • Alto desempenho e suporte para aplicações complexas • Oferece segurança e certificação ◦ Para setores aeroespacial e militar • Compatível com várias arquiteturas ◦ x86, ARM, PowerPC • Principais usos ◦ Aeronáutica ◦ Telecomunicações ◦ Indústria automotiva
16. QNX • Sistema comercial • Arquitetura de microkernel que melhora a estabilidade e segurança • Suporte para interfaces gráficas (HMI) • Escalável para dispositivos embarcados complexos • Principais usos ◦ Sistemas automotivos (infotainment) ◦ Dispositivos médicos ◦ Automação industrial
17. PREEMPT-RT Linux em Tempo Real
18. História • Desenvolvimento iniciou em 2005 • Ao longo dos anos vários patches foram aceitos no Linux mainline • Em 20/09/2024 todos os patches foram aceitos no Linux mainline • Kernel 6.12 é a primeira versão de tempo real ◦ Apenas para x86_64, arm64 e RISC-V
19. Porque usar? • Compatibilidade POSIX • Suporte a uma variedade grande de hardware • Executar RT e não RT ao mesmo tempo • Portabilidade • Familiaridade no desenvolvimento • Comunidade ativa
20. Porque não usar? • O hardware Linux não é pensado para tempo real • A latência não é a mais baixa • O desempenho de aplicações pode ser afetado • Complexo e com overhead • Certificações de segurança
21. Latência • Tempo entre um evento (entrada) e a resposta do sistema (saída) • Latência inesperada causa indeterminismo • Pode ser causada tanto por software como por hardware • Em alguns casos é possível mitigar
22. Latência por hardware • Cache Levels • Page Fault • Simultaneous Multi-Threading (SMT) • Non-Uniform Memory Access (NUMA) • Branch prediction • Low-level firmware • Falhas de hardware
23. Latência por software • Inversão de prioridade • Locks • Timers • Printk • Interrupts • Watchdogs • Debugging
24. Contextos de execução • Código executando em kernel mode pode ter diferentes contextos ◦ Non-Maskable Interrupt (NMI) ▪ Contexto para interrupções não-mascaráveis ▪ Geralmente usado para falhas de hardware ◦ Hard Interrupt (hardirq) ▪ Contexto para interrupções de hardware (I/O) ◦ Software Interrupt (softirq) ▪ Contexto para interrupções de software ◦ Tarefa (task) ▪ Contexto normal de execução de processos e threads em kernel mode e userspace • Algumas operações são proibidas de acordo com o contexto
25. Preempção • Capacidade de parar o que a CPU esteja executando para executar outra tarefa • Útil para um GPOS ◦ Para compartilhar tempo de execução • Crítico para um RTOS ◦ Para executar tarefas críticas • Qualquer tarefa deve ser preemptiva ◦ Tanto em userspace quanto em kernelspace
26. Inversão de prioridade • Quando uma tarefa de alta prioridade é bloqueada por uma tarefa de menor prioridade ◦ Devido a um recurso compartilhado • O kernel oferece políticas de agendamento que suportam herança de prioridade ◦ Não sofre com inversão de prioridade • O kernel pode aumentar a prioridade de uma tarefa de baixa prioridade ◦ Executa o mais breve possível para liberar o recurso bloqueado
27. Locks • Usados para arbitrar o acesso simultâneo a um recurso compartilhado • Existe vários tipos de locks no kernel e em userspace • Tipos de locks no Kernel ◦ Sleeping locks ◦ Spinning locks ◦ CPU Local locks
28. Sleeping locks • “Dormem” e “acordam” enquanto esperam • Vários tipos de locks ◦ mutex ◦ rt_mutex ◦ semaphore ◦ rw_semaphore ◦ ww_mutex ◦ percpu_rw_semaphore • Não pode ser usado em contextos NMI, hardirq e softirq ◦ Não são preemptíveis ◦ Introduz latência ◦ Pode causar deadlocks
29. Spinning locks • Continua tentando acessar os recursos até que eles sejam liberados • Vários tipos de locks ◦ spinlock_t ◦ rwlock_t ◦ raw_spinlock_t • Desabilita preempção durante sua execução ◦ Para proteger áreas críticas ◦ Para manter consistência e sincronia em tarefas de baixo nível • Pode ser usado em qualquer contexto, mas com cuidado • Com PREEMPT_RT spinlock_t and rwlock_t viram sleeping locks (rt_mutex) ◦ Para aumentar o determinismo ◦ Spinning locks consomem muita CPU
30. CPU Local locks • Protege dados acessados por apenas uma CPU • Apenas um tipo de lock ◦ local_lock • Bloqueio simples que previne interferência ◦ De interrupts e preempção de outras tarefas • Com PREEMPT_RT local_lock viram sleeping locks (rt_mutex)
31. Timers • Timers agendam a execução de tarefas • A resolução costuma ser vinculada à resolução do sistema ◦ Normalmente 100 Hz ou 250 Hz ◦ Depende da arquitetura da CPU e de configuração do kernel ◦ Resolução de apenas 10 ms ou 4 ms
32. High Resolution Timers (hrtimers) • Precisão em nanosegundos • Essencial com PREEMPT_RT para manter o determinismo ◦ Uso garantido em tarefas críticas • São multiplexados ◦ Um único temporizador de hardware é suficiente para um grande número de temporizadores por software • Pode ser usado por userspace
33. Printk • Um dos principais mecanismos de log no kernel ◦ Usado para mensagens, debug e tracing ◦ Pode ser lido com o dmesg • Funciona em todos os contextos de execução • Causa latência por bloquear a execução enquanto grava o log ◦ Uma tarefa de baixa prioridade pode bloquear uma tarefa de alta prioridade gravando muitos dados • Foi a última mudança do patch RT a entrar no Linux mainline • Com PREEMPT_RT a gravação do log pode ser adiada ◦ Executa em um thread que não bloqueia outras tarefas de tempo real
34. Interrupts • Um interrupt altera a execução na CPU • O kernel precisa tratar um interrupt assim que ele acontece • Durante a execução de um interrupt outras tarefas são bloqueadas ◦ O que pode causar latência inesperada • Com PREEMPT_RT quase todos interrupts são executados em um thread ◦ O kernel aceita o interrupt e o coloca em uma fila ◦ Exceções IRQF_NOTHREAD, IRQF_PERCPU e IRQS_ONESHOT
35. Watchdogs • O kernel pode atuar como um watchdog • Detectando hard e soft lockups • Essas tarefas são executadas com prioridade em tempo real 99 ◦ Pode introduzir latências
36. Debugging • Existem muitas opções de debug no kernel • Úteis para debug mas que podem introduzir latências ◦ Devido a uma grande quantidade de log e outras verificações
37. Modos de preempção • O kernel possui alguns modelos de preempção • CONFIG_PREEMPT_NONE ◦ No Forced Preemption (server) • CONFIG_PREEMPT_VOLUNTARY ◦ Voluntary Kernel Preemption (Desktop) • CONFIG_PREEMPT ◦ Preemptible Kernel (Low-latency Desktop) • CONFIG_PREEMPT_RT ◦ Fully Preemptible Kernel (Real-Time)
38. CONFIG_PREEMPT_NONE • Código do kernel não é preemptivo ◦ Interrupts ◦ Exceptions ◦ System calls • Ideal para sistemas com computação intensa (servidor) • Latência alta • Não determinístico
39. CONFIG_PREEMPT_VOLUNTARY • Código do kernel pode ser preemptivo • Ideal para desktop • Impacto mínimo no desempenho • Latência moderada • Não determinístico
40. CONFIG_PREEMPT • O kernel pode ser preemptivo ◦ Exceção para partes críticas do kernel (spinlocks) • Ideal para sistemas embarcados • Impacto baixo no desempenho • Latência baixa • Quase determinístico
41. CONFIG_PREEMPT_RT • Praticamente todo código do kernel pode ser preemptivo • spinlocks viram sleeping locks ◦ Apenas raw_spinlock_t continua sendo um spinning lock • Praticamente todos interrupts são executados em um thread • Ideal para sistemas com requisitos de tempo real • Latência muito baixa • Determinístico
42. Ferramentas
43. Latência • cyclictest ◦ Ferramenta mais usada para medir a latência do sistema ◦ Testa a diferença de tempo entre despertares programados e despertares reais de um thread em execução em uma CPU específica. • hwlatdetect ◦ Detecta latência de hardware introduzida por interrupts e SMI • signaltest ◦ Mede a latência de entrega de sinal entre threads ou processos • svsematest ◦ Mede a latência de semáforos em um contexto de tempo real • pi_stress ◦ Testa o mecanismo de herança de prioridade ◦ Detecta problemas com inversão de prioridade
44. Tracing e Profiling • Ftrace ◦ Ferramenta para rastrear funções e eventos do kernel ◦ Pode ser usado para medir latência no início de tarefas, atrasos no agendamento ou interrupts • Trace-cmd ◦ Interface amigável para o Ftrace ◦ Usado para visualizar eventos durante a execução de tarefas • Perf ◦ Ferramenta para testar desempenho e latência
45. Teste de stress • stress-ng ◦ Ferramenta versátil ◦ Gera carga para recursos específicos (CPU, memória, I/O) ◦ Pode criar um ambiente como uma carga alta para testes de latência • hackbench ◦ Simula criação de threads e processos para estressar o scheduler e mede o impacto
46. Perguntas?
47. Obrigado