Esta pode ser uma pergunta "você é burro", mas neste momento estou esperando apenas um novo caminho para olhar para baixo.
Executamos alguns softwares em vários sistemas em realtime priority ( SCHED_FIFO , Priority: 99 ) Para atingir determinados requisitos de estrutura no software em que nossos engenheiros trabalham.
um de nossos projetos paralelos não "realmente" precisa do mesmo desempenho em tempo real, mas eles precisam de alguma funcionalidade que só é possível quando executado em tempo real. As falhas do frame do IE não são um estado crítico de falha, mas elas precisam ser tentadas e acertadas para que certas outras coisas aconteçam de maneira apropriada. É uma bagunça confusa.
De qualquer forma, durante a execução do software em tempo real, eles também usam o sistema para outras tarefas rápidas, geralmente abrindo janelas de terminal, executando um programa rápido, e então Ctrl + d largue o terminal e siga em frente com sua vida. Isso deixa cópias dos aplicativos em um modo de suspensão ininterrupto, que com o tempo consome recursos do sistema e bloqueia o sistema. Se o software for interrompido, ele imediatamente resolve todos esses processos e termina de fechar tudo.
Meus pensamentos são de que qualquer processo de limpeza executado para concluir a limpeza desses processos simplesmente não será concluído com o sistema mantendo a prioridade em tempo real sobre as coisas. Eu percebo "não é assim que você deve usar um sistema em tempo real" e tudo isso, mas infelizmente é um problema que eles se recusam a admitir, e eu tenho que encontrar uma solução mágica para um problema simples (não usar um sistema em tempo real como estação de trabalho.)
Então, minha pergunta é: existe uma maneira de forçar manualmente o processo de limpeza de vez em quando a ter precedência sobre o processo de execução máximo?
Eu considerei tentar ficar chique com cgroups , mas isso parece uma solução muito complicada para o problema, e uma que eu não tenho certeza irá realmente funcionar mesmo que eu tenha tempo para aprender a trabalhar bem com cgroups e as várias estatísticas de tempo do kernel