Forum Linux.général Utilité d'utiliser un noyau RT ?

Posté par  . Licence CC By‑SA.
Étiquettes :
6
16
juil.
2025

Bonjour,

Je vois fleurir sur le web des avis qui suggèrent d'activer le noyau "temps réel" (real time ou RT) qui serait bienvenu pour un usage bureautique et/ou jeu (gaming).

Debian (13 "Trixie") rend l'activation de cette option assez facilement, puisqu'il suffit d'ajouter l'option "preempt=full" dans le fichier de configuration de GRUB (/etc/default/grub) à la ligne "GRUB_CMDLINE_LINUX_DEFAULT=" et de redémarrer.

exemple :

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash preempt=full"

Quel serait l'intérêt de ce paramétrage ? Mais quels en seraient les inconvénients (s'il y en a) ?

  • # Explications

    Posté par  (site web personnel) . Évalué à 4 (+1/-0).

    Les modèles de prémption du noyau Linux https://wiki.linuxfoundation.org/realtime/documentation/technical_basics/preemption_models

    The “Fully Preemptible Kernel” preemption model must be selected to obtain Linux as an RTOS.

    On a donc bien l'explication que "full" donne un système d'exploitation temps réel.

    L'idée, si je comprends bien, est que si de multiples tâches sont en cours, et que l'on a assez de cœurs processeur (probablement le cas de tout CPU désormais) on peut améliorer la latence (disons une vidéo plus fluide par exemple), éventuellement au détriment du débit de données traités (la recherche sur disque un peu plus lente car la vidéo sera privilégiée par exemple).

    Pour du jeu ou de la MAO, ça me paraît assez logique sur le papier ; pour de la bureautique je ne vois pas trop pourquoi. D'autres seront sans doute à même de préciser/détailler.

    Il y a des noyaux RT chez Debian sinon
    https://packages.debian.org/search?suite=trixie&searchon=all&keywords=PREEMPT_RT

    • [^] # Re: Explications

      Posté par  (site web personnel) . Évalué à 10 (+14/-0).

      Le temps réel pour la bureautique n'est pas nécessaire. Ni même pour les jeux vidéo.

      En fait le concept de temps réel pour un système d'exploitation est une notion plutôt industrielle et peu intuitive. L'idée est qu'un système d'exploitation réalise de nombreuses tâches provenant de plein de sources d'entrées (clavier, souris, réseau, autres) et doit aussi permettre d'exécuter des processus divers.

      Sauf que dans de nombreux cas, on souhaite avoir la garantie que les entrées et que certains processus soient exécutés au plus tard dans (par exemple) 10 millisecondes. Dans le milieu industriel les cas d'exemple sont légions, on peut penser à un système pour lequel on souhaite que des vérifications ou procédures d'arrêt puissent s'exécuter dans tous les cas à une vitesse assez vite.

      C'est le cas aussi dans certains protocoles avec des timings très précis, par exemple dans un projet industriel sur lequel je travaille, il faut être capable de renvoyer sur le port série une réponse 6 millisecondes au plus tard (et 3 millisecondes au plus tôt) après une requête. Sans temps réel, il est facile pour Linux de manquer ces objectifs et donc la communication va avoir beaucoup de rater selon l'état du système. Avec le temps réel on peut dire au noyau "ce processus a des contraintes temps réels" et le noyau fera en sorte que les réponses sortent à la bonne cadence pour respecter le protocole.

      Cependant cette garantie de temps de réaction se fait souvent de manière contre intuitive au détriment de la performance brute. En fait on essaye de borner la latence maximale dans le pire cas du système mais pour cela on augmente en général la latence moyenne. L'utilisateur bureautique souhaite en général qu'en moyenne cela soit le plus rapide possible, et de temps en temps si le système a une latence un peu plus longue au niveau du système cela n'a aucune importance. D'autant plus que dans la majorité des cas, le soucis n'est pas au niveau de l'OS mais est au niveau applicatif.

      Pour la MAO cela a du sens car la moindre latence en dehors de la limite acceptable dans le traitement du son peut se répercuter dans le rendu final. Mais c'est de moins en moins vrai avec l'amélioration des performances globales de la machine qui font que les situations où on est hors des clous pour ce cas d'usage sont de plus en plus rare même sans temps réel dur.

      • [^] # Re: Explications

        Posté par  (site web personnel, Mastodon) . Évalué à 1 (+0/-0). Dernière modification le 17 juillet 2025 à 23:46.

        Il faut d'abord rappelé qu'il faut que les logiciels soient écrits pour être temps réel, ce qui n'est pas le cas de la plupart. Cependant il est possible que les moteurs de jeux ou d'autres puissent l'être.

        A ce moment je dirais qu'il y a un intérêt à s mettre temps réel si tu as de la marge de puissance/IO. Autrement dit si tu veux faire tourner un seul logiciel seul de manière fluide et précise. Mais à partir du moment ou tu en a plusieurs, ils risquent d'entrer en concurrence inutilement et faire baisser drastiquement les performances des autres logiciels voire des autres process du logiciel. Typiquement, je ne pense pas que le navigateur soit conçu temps réel, il risque donc de souffrir car il ne préemptera pas or c'est le soft n°1 aujourd'hui.

        Pour un PC de jeux, c'est peut-être utile pour améliorer la réactivité… a condition que cela ne pénalise pas trop les processus intelligence. Or généralement, les jeux ont peu de marge de puissance car quand c'est le cas on préfère augmenter la qualité (définition de l'image, taux de rafraichissement, détails des scénarios…). Mais si tu en a tu peux petut-être gagner des mili-secondes au mouvement de souris

        Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.

        • [^] # Re: Explications

          Posté par  (site web personnel) . Évalué à 6 (+3/-0).

          Il faut d'abord rappelé qu'il faut que les logiciels soient écrits pour être temps réel,

          Pour en tirer pleinement bénéfice, oui.
          Mais les effets d'un noyau temps réels s'appliquent même si tes applications ne sont pas conçues dans cette optique.

          C'est d'ailleurs aussi le problème, activer le temps réel sur un système où ça n'a pas d'intérêt peut réduire les performances globales car tu mets en place des restrictions qui n'ont pas de sens dans ce contexte.

          Cependant il est possible que les moteurs de jeux ou d'autres puissent l'être.

          Non, les OS grands publics tels que Windows ou macOS et même Linux jusqu'à récemment n'étaient pas temps réels durs. Peu d'intérêt de les développer avec cela en tête, surtout que les contraintes du JV sont souvent mou (si ton PC est trop lent, on saute une frame et voilà).

          Typiquement, je ne pense pas que le navigateur soit conçu temps réel, il risque donc de souffrir car il ne préemptera pas or c'est le soft n°1 aujourd'hui.

          Système temps réel n'implique pas préemption collaborative, c'est même jamais le cas sinon tu n'as que peu de moyen de garantir un délai d'exécution bornée.

          D'ailleurs le fait que le noyau ne rendait pas la main dans certains cas (notamment lors des communications sur port séries / terminaux) était une limitation de Linux dans ce domaine et qui faisait qu'il fallait se trimballer le correctif RT pour lever ces obstacles.

          Pour un PC de jeux, c'est peut-être utile pour améliorer la réactivité…

          Mon message explique que globalement c'est faux. Tu donnes des garantie de réactivité minimale, mais souvent au détriment de la réactivité moyenne.

          Puis bon le concept de temps réel alors qu'on implique un composant aussi complexe qu'un GPU à côté qui fait lui même des calculs très sophistiqués, c'est tout un programme. :D

          Mais si tu en a tu peux petut-être gagner des mili-secondes au mouvement de souris

          Non.

          Car dans un JV le pipeline est très spécifique : entrée (souris) -> calculs d'actions -> rendu de l'image -> affichage sur écran en boucle. Le fait de capturer le mouvement de la souris un peu plus tôt n'a pas forcément d'impact si le JV est aux étapes suivantes dans sa suite de calcul. Cela sera toujours pris en compte pour la frame suivante.

          En fait pour le JV ce n'est pas le temps réel qui compte vraiment, c'est l'ordonnancement global. Pour notamment s'assurer que tu n'interromps pas le JV pour d'autres tâches subsidiaires au mauvais moment. Ou que par exemple dans ta pile de threads qui compose ton jeu certains soient réveillés pour rien ou à un moment par propice car ce n'est pas le bon moment selon le statut du pipeline.

          Il y a des démos de setup d'ordonnancements maisons avec sched_ext (en gros pouvoir modifier l'ordonnancement du noyau à la volée de manière sûre) dans le cadre des jeux et les gains étaient largement possibles en jouant dessus. Aucun rapport avec le temps réel cependant.

    • [^] # Re: Explications

      Posté par  . Évalué à 3 (+1/-0).

      Chez Arch officiel, deux types de noyaux RT: linux-rt 6.14.0.rt3.arch1-1 et linux-rt-lts 6.6.87.rt54.arch1-1 (version longue durée)
      https://archlinux.org/packages/?sort=&q=linux-rt&maintainer=&flagged=

    • [^] # Re: Explications

      Posté par  . Évalué à 1 (+0/-0).

      Merci pour vos réponses éclairées !

Envoyer un commentaire

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.