Utilizando sched_rt_period_us para definir o tempo máximo entre as chamadas de tarefa na ordem de 10 ms

Question

Entendo que sched_rt_period_us e sched_rt_runtime_us são destinados a impedir o congelamento do sistema no caso de uma tarefa de RT em fuga. Pergunto-me, porém, se é possível usar um pequeno valor de sched_rt_period_us para garantir que a tarefa esteja sendo executada sem problemas.

Eu tenho um trabalho simples que requer não mais do que um milissegundo ou mais de tempo de CPU por chamada - digamos, dirigindo um motor de passo sobre os pinos do GPIO. Eu gostaria de alcançar nada menos que 100 ciclos por segundo, porém, sustentado. Isso não é mais que 10% do tempo da CPU - descontando a sobrecarga de preempção e agendador.

Eu li "valores muito pequenos em sched_rt_period_us podem resultar em um sistema instável" ¹ mas não foi dito que ordem de magnitude conta para" um valor muito pequeno ". Posso confiar com confiabilidade em não mais do que 0,01s de atraso entre as chamadas para o meu programa se eu definir sched_rt_period_us para 10000 e retornar o controle ( sched_yield() ) de maneira oportuna?

A CPU subjacente provavelmente seria de 850MHz ARM com várias outras tarefas além do controle, mas nenhuma delas em tempo real ou mesmo necessária para "sentir-se responsiva", ainda assim, diferentemente dos padrões de sched_rt_period_us e sched_rt_runtime_us (95 % de 1s) Eu não posso permitir que a tarefa de RT durma 0,05s de cada vez.

    

Answer 1

Essa é uma pergunta tão antiga, vamos tentar. Como eu entendi você está usando o mecanismo anti-deadlock ( this ) para evitar inanição de seus processos normais por causa de seu processo de RT.

Você diz que

I have a simple job that requires no more than a millisecond or so of CPU time per call

É uma tarefa periódica curta ou uma tarefa curta iniciada por uma entrada externa?

Para o primeiro caso ( tarefas de curto período ): você deve saber que no kernel 3.14 do Linux ficou disponível a classe SCHED_DEADLINE . Isso permite que você defina uma política de programação para seus processos para que eles tenham pelo menos tanto tempo de CPU periodicamente. Dê uma olhada na documentação , você também encontrará um diagrama compreensível no SCHED_DEADLINE seção em man 7 sched . Se o gatilho for externo (aleatório, não periódico), talvez não seja a solução.

Para o segundo caso ( tarefa esporádica curta ): Se você puder afirmar que seu programa fará apenas um pequeno trabalho toda vez que for necessário, você pode tentar parar de usar prioridades e apenas chamar sched_yield depois que seu trabalho terminar. É uma abordagem ba se ocupado-pooling. Se você realmente precisa de prioridades, talvez possa complementá-lo com sleep , processos não-rt será executado enquanto o processo RT estiver inativo. Você também pode saber que, se ele for acionado por interrupções, talvez você deva usar metades inferiores , abordagem mais difícil.

Mmmm e mais: você deve ter em mente que pode aparecer mais processos em tempo real do que os seus. Por exemplo, existem threads do kernel .

Espero que ajude, com os melhores cumprimentos,

/ Ángel

    

Answer 2

Não há muito o que encontrar relacionado a esta questão, mas encontrei este tópico. É um pouco datado de 2009, e é sobre o kernel Linux 2.6.X, mas parecia apto.

O título deste tópico, Assunto: pergunta sobre o limite de alocação do grupo sched-rt: sched_rt_runtime_us - msg # 01766 .

trecho

I have written a small test program that:

(a) forks two threads, one SCHED_FIFO and one SCHED_OTHER (this thread is reniced to -20) and ties both of them to a specific core.

(b) runs both the threads in a tight loop (same number of iterations for both threads) until the SCHED_FIFO thread terminates.

(c) calculates the number of completed iterations of the regular SCHED_OTHER thread against the fixed number of iterations of the SCHED_FIFO thread. It then calculates a percentage based on that.

I am running the above workload against varying sched_rt_runtime_us values (200 ms to 700 ms) keeping the sched_rt_period_us constant at 1000 ms. I have also experimented a little bit by decreasing the value of sched_rt_period_us (thus increasing the sched granularity) with no apparent change in behavior.

My observations are listed in tabular form:

Ratio of # of completed iterations of reg thread / sched_rt_runtime_us / # of iterations of RT thread (in %) sched_rt_runtime_us

• 0.2 100 % (regular thread completed all its iterations).
• 0.3 73 %
• 0.4 45 %
• 0.5 17 %
• 0.6 0 % (SCHED_OTHER thread completely throttled. Never ran)
• 0.7 0 %