Negativos de processos em execução com prioridade em tempo real?

Existem desvantagens nos processos em execução com prioridade em tempo real ( chrt -f 99)?

Minha hipótese é que isso combinado com uma afinidade garantirá que qualquer preferência do meu processo seja mínima e, portanto, qualquer instabilidade (especificamente a latência da rede) será minimizada - isso não ajudará na latência geral, mas, neste momento, estou mais preocupado com jitter.

(Kernel: 2.6.16 / 3.0)

linux process real-time

— Nim
fonte

Isso parece útil para você: Como reduzir o jitter para Java?

— ire_and_curses

@ire_and_curses, atualmente o processo é executado em seu próprio núcleo isolado (pelo menos no segmento de processamento principal), no entanto, as interrupções não são agendadas no mesmo núcleo (não é possível fazer isso, pois existem vários processos similares na mesma interface de rede) ), este é mais um último esforço. A frequência APIC é interessante, eu nunca encontrei isso antes.

— Nim

A desvantagem mais imediata da execução de um processo em tempo real é que ele pode facilmente passar fome por todos os outros processos do sistema. O resultado do seu ponto de vista será que o computador não responde totalmente ao teclado, mouse e provavelmente à rede, enquanto o processo em tempo real estiver usando a CPU. Isso pode acontecer se algo der errado e o processo entrar em um loop infinito, ou mesmo temporariamente, se o processo iniciar um cálculo de longa execução sem esperar pela entrada periódica. (Portanto, por exemplo, não execute o SETI @ home com prioridade em tempo real.)

Um processo único de thread único em uma CPU com vários núcleos tem menos probabilidade de causar esse problema, pois existem outros núcleos que o processo de prioridade mais baixa pode usar. Mas se esse processo criar algum processo filho, ele herdará a mesma prioridade em tempo real, para que as coisas fiquem fora de controle se você não for cuidadoso.

A sched_setscheduler(2)página de manual tem bons conselhos:

Como um loop infinito sem bloqueio em um processo agendado em SCHED_FIFO ou SCHED_RR bloqueará todos os processos com prioridade mais baixa para sempre, um desenvolvedor de software sempre deve manter disponível no console um shell agendado com uma prioridade estática mais alta que o aplicativo testado. Isso permitirá uma interrupção emergencial dos aplicativos testados em tempo real que não bloqueiam ou terminam conforme o esperado. Consulte também a descrição do limite de recurso RLIMIT_RTTIME em getrlimit (2).

Esse deve ser um shell no console - não no Xterm, a menos que você queira também dar prioridade ao X em tempo real.

— Jander
fonte

Sim - este é o principal problema que pareço encontrar. Sem ler o código do kernel para determinar todos os processos que precisam ter uma prioridade mais alta, a única opção é deixar todos os outros de fora do meu processo e depois mover qualquer coisa que exija qualquer forma de io para outros núcleos ... hmmm. ..

— Nim