Existe uma boa maneira de pesquisar em um processo em tempo real que seja amigável ao kernel?

Question

Eu tenho um aplicativo que usa boost asio e gostaria de usar poll() para detectar eventos de rede prontos (pacotes) e processá-los o mais rápido possível.

Além disso, eu gostaria de usar SCHED_FIFO para este processo (que é single threaded) tentar controlar o jitter (problema principal que estou tentando resolver ..)

Agora, a limitação é que o kernel é 2.6.32 (sem patch em tempo real). O problema adicional é que existem alguns processos do kernel que rodam no núcleo onde meu aplicativo está rodando e que eu não consigo mover (isto é, o O kernel não parece ter isolamento verdadeiro - eu sei que isso vem em um kernel posterior - mas eu não posso atualizar para isso ainda.)

Então, agora, se eu sou hostil e faço o seguinte:

while(some_condition)
  service.poll();

Este processo irá girar o núcleo, e como SCHED_FIFO está definido, ele nunca irá abandonar os outros processos do kernel que precisam ser executados neste núcleo, e todo tipo de coisas ruins imprevisíveis acontece. Agora, minha pergunta é: como posso fazer esse loop de poll e garantir que eu abandone para que os outros threads sejam executados por um pouco, pelo menos?

vejo duas opções,

1. Algum tipo de sono
2. se nenhum evento foi tratado por poll() , eu poderia chamar run_one() , que bloqueia apenas um evento, mas o problema aqui é que esse evento pode ser o pacote que eu quero, e agora eu tenho jitter novamente ...

Eu perdi outras abordagens?

    

Answer 1

Eu não usei Boost::asio , mas, à primeira vista, parece que você deseja usar .run() e não .poll() . Como Patrick aponta, a chamada de sistema poll() normativa pode bloquear passivamente, enquanto asio::poll() explicitamente não (exigindo loop ocupado), mas run() :

The run() function blocks until all work has finished and there are no more handlers to be dispatched, or until the io_service has been stopped.

Naturalmente, isso não resolve o problema se você estiver lidando com um fluxo contínuo de pacotes - mas, em seguida, acho que você foi recuado para um canto. Se o sistema deve fazer uso periódico desse núcleo, e você também deve usar apenas esse núcleo, e desistir dele introduz a latência em seu manuseio, que é uma rocha e um lugar difícil.