Tenho uma pergunta sobre o suporte "Realtime" no Linux/Ubuntu:
Após alguma pesquisa sobre o tópico, parece que o suporte "em tempo real" no Linux é duplo: por um lado, há o patch PREEMPT_RT , que traz recursos de "computação em tempo real" para o kernel do Linux; por outro lado, há as chamadas estratégias de agendamento "em tempo real" , como SCHED_FIFO, SCHED_RRe SCHED_DEADLINE, que estão disponíveis há muito tempo.
Mas como tudo isso acontece?
O que acontece se eu usar uma das estratégias de agendamento "em tempo real" (por exemplo, SCHED_DEADLINE) em um kernel "vanilla", ou seja, um que não tenha PREEMPT_RThabilitado? Alguém poderia supor que isso nem seja possível. Mas parece que é possível, de acordo com meu teste em um kernel "vanilla" (não em tempo real)! O que isso significa? As estratégias de agendamento "em tempo real" ainda funcionam com o kernel "não em tempo real", mas não "tão bem"? Ou isso significa que as estratégias de agendamento "em tempo real" silenciosamente são as mesmas de SHED_OTHERquando executadas em um kernel "não em tempo real"?
Além disso, supondo que eu esteja usando um kernel "em tempo real", ou seja, um que tenha habilitadoPREEMPT_RT : haverá alguma diferença, em comparação com um kernel "vanilla" (não em tempo real), se eu não iniciar explicitamente nenhum processo com uma das estratégias de agendamento "em tempo real"?
(Pergunta bônus: como a "gentileza" interage com o agendamento "em tempo real"? Tenho procurado informações, mas todas as fontes explicam "gentileza" apenas no contexto de SHED_OTHER)
Estratégias de agendamento e “preemptividade” do kernel são preocupações separadas, mas complementares.
Estratégias de agendamento determinam como o agendador escolhe qual tarefa executar em seguida, sempre que for solicitado a reprogramar. Isso pode ser implementado amplamente independentemente de quantas vezes (e se) o kernel pode ser preemptado, e elas fazem a diferença até mesmo em kernels não não em tempo real — aplicar estratégias e prioridades criteriosamente garante que tarefas importantes sejam executadas mais cedo.
No entanto, atingir o agendamento em “tempo real”, ou seja, agendamento com prazos, requer garantir que as tarefas possam ser executadas em um determinado horário. É aqui que entra a preemptividade do kernel. Historicamente, o kernel não podia ser interrompido, então sempre que o kernel estava ocupado, as tarefas não podiam ser agendadas (em um determinado núcleo de CPU). Mas, conforme descrito em
man 7 sched:O kernel vem adicionando progressivamente mais e mais recursos de estilo em tempo real, culminando no
PREEMPT_RTque foi disponibilizado no kernel principal em algumas arquiteturas na versão 6.12:A última frase explica como tudo isso se encaixa: melhorar a preemptividade do kernel significa dar mais controle ao planejador, o que permite que ele satisfaça melhor as demandas impostas a ele pelas diversas estratégias.
Portanto, as várias estratégias fazem a diferença mesmo em não
PREEMPT_RTkernels (porque elas mudam como o agendador escolhe a próxima tarefa a ser executada) ePREEMPT_RTfazem a diferença mesmo se apenasSCHED_OTHERfor usada (porque isso resulta em mais oportunidades para o agendador alternar tarefas).Veja também Por que alguém escolheria não usar o kernel de baixa latência? e a documentação do kernel sobre os vários tipos de bloqueio que ele suporta .
A gentileza não é levada em consideração ao agendar usando
SCHED_FIFO,SCHED_RR, ouSCHED_DEADLINE.