Négatifs de l'exécution de processus avec priorité en temps réel?

Existe-t-il des inconvénients à exécuter des processus avec une priorité en temps réel ( chrt -f 99)?

Mon hypothèse est que cela combiné à une affinité garantira que toute préemption de mon processus est minimale et donc toute gigue (en particulier la latence du réseau) sera minimisée - cela n'aidera pas la latence globale, mais en ce moment, je suis plus préoccupé par la gigue.

(Noyau: 2.6.16 / 3.0)

linux process real-time

— Nim
source

Cela vous semble utile: comment réduire la gigue pour Java?

— ire_and_curses

@ire_and_curses, actuellement le processus s'exécute sur son propre noyau isolé (au moins le thread de traitement principal), mais les interruptions ne sont pas planifiées sur ce même noyau (ne peut pas le faire car il existe plusieurs processus similaires reposant sur la même interface réseau ), c'est plus un dernier effort.La fréquence APIC est intéressante, je ne l'ai pas rencontrée auparavant.

— Nim

L'inconvénient le plus immédiat de l'exécution d'un processus en temps réel est qu'il peut facilement éliminer tous les autres processus du système. Le résultat de votre point de vue sera que l'ordinateur ne répond pas du tout au clavier, à la souris et probablement au réseau, tant que le processus en temps réel utilise le CPU. Cela peut se produire si quelque chose se passe mal et que le processus entre dans une boucle infinie, ou même temporairement si le processus démarre un calcul à long terme sans attendre périodiquement une entrée. (Ainsi, par exemple, n'exécutez pas SETI @ home avec une priorité en temps réel.)

Un processus monothread unique sur un processeur multicœur est moins susceptible de provoquer ce problème car il existe d'autres cœurs que le processus de priorité inférieure peut utiliser. Mais si ce processus crée des processus enfants, ils hériteront de la même priorité en temps réel, de sorte que les choses peuvent devenir incontrôlables si vous ne faites pas attention.

La sched_setscheduler(2)page de manuel contient de bons conseils:

Étant donné qu'une boucle infinie non bloquante dans un processus planifié sous SCHED_FIFO ou SCHED_RR bloquera à jamais tous les processus avec une priorité inférieure, un développeur de logiciel devrait toujours garder disponible sur la console un shell planifié avec une priorité statique plus élevée que l'application testée. Cela permettra une suppression d'urgence des applications testées en temps réel qui ne bloquent pas ou ne se terminent pas comme prévu. Voir aussi la description de la limite de ressources RLIMIT_RTTIME dans getrlimit (2).

Cela devrait être un shell sur la console - pas sous un Xterm, à moins que vous ne souhaitiez également donner la priorité à X en temps réel.

— Jander
source

Oui - c'est le principal problème que je semble rencontrer. À moins de lire le code du noyau pour déterminer tous les processus qui doivent avoir une priorité plus élevée, la seule option est de priver tous les autres de mon processus, puis de déplacer tout ce qui nécessite n'importe quelle forme d'io vers d'autres cœurs ... hmmm. ..

— Nim