L’objectif final de la préemption temps réel

L’aboutissement du support de la préemption temps réel sous Linux

• Le travail visant à ajouter le support temps réel à Linux a commencé en 2004 et entre désormais dans sa phase finale.
• L’objectif de la préemption temps réel est de permettre au processus de plus haute priorité de s’exécuter avec un délai minimal ; pour cela, le noyau est rendu préemptible dans autant de situations que possible.
• Ce travail a conduit à une réécriture de parties essentielles du noyau et apporte des bénéfices qui vont au-delà des cas d’usage temps réel.

Résolution du problème de printk()

• La fonction printk(), utilisée dans le noyau pour envoyer des messages vers la console système et les logs, fonctionne de manière synchrone et ne retourne pas tant que le message n’a pas été transmis à toutes les destinations configurées.
• Les développeurs temps réel ont déplacé la sortie de printk() vers un thread séparé pour la rendre asynchrone, mais il ne s’agissait que d’une solution provisoire.
• Le problème de printk(), traité sérieusement depuis 2018, est en voie de résolution au travers d’environ 300 patchs, même s’il reste encore quelques problèmes complexes à régler.

Perspectives d’intégration du code de préemption temps réel dans la branche principale

• L’espoir est exprimé que le reste du code de préemption temps réel soit intégré dans la branche principale avant son 20e anniversaire, fin 2024.
• Il n’y a pas eu de changement récent dans le code de printk(), mais le code de handover a été modifié pour permettre la mise à jour des pilotes de console un par un.
• Le code a été modifié pour que les messages importants soient entièrement copiés dans le tampon de messages avant l’affichage de la première ligne, et pour enregistrer d’abord les messages sur une console sûre afin d’éviter les plantages du système causés par des pilotes de console défectueux.

L’avis de GN⁺

• Le travail d’ajout du support de la préemption temps réel au noyau Linux est presque achevé, ce qui apportera des bénéfices importants aux systèmes ayant besoin de traitements temps réel.
• Le passage de la fonction printk() à un fonctionnement asynchrone améliore la réactivité du système et joue un rôle essentiel dans l’atteinte des objectifs de la préemption temps réel.
• Cet article montre une avancée importante du développement du noyau Linux et propose un contenu intéressant pour les personnes qui s’intéressent à son développement.

[GN⁺]

Avis de Hacker News

• Les avantages du microkernel QNX

  • Le microkernel QNX garantit la fiabilité depuis des décennies en imposant une borne supérieure à chaque opération.
  • Le code du microkernel ne compte que quelques dizaines de milliers de lignes et ne s’occupe que de l’allocation mémoire, de l’ordonnancement CPU et du passage de messages entre processus.
  • Toutes les autres fonctions, y compris les pilotes et le logger, s’exécutent en espace utilisateur et peuvent être préemptées par des threads de plus haute priorité.
  • Le noyau QNX n’effectue aucune opération sur les chaînes de caractères, ce qui évite les problèmes liés au parsing, au formatage et à la transmission de messages.

• Les problèmes du traitement temps réel sous Linux

  • Linux repose sur une architecture peu adaptée au temps réel, avec un code noyau qui se compte en millions de lignes et dont chaque partie doit pouvoir être préemptée.
  • Il a fallu des décennies pour corriger cela en raison de son inadéquation en tant qu’architecture temps réel.
  • Se focaliser uniquement sur les problèmes du noyau peut faire passer à côté des limites au niveau du CPU.

• La journalisation du noyau et les cas d’usage réels

  • Explication de la façon dont les exemples montrant jusqu’où le noyau va pour afficher des messages de log, même quand le système est en train de tomber, sont utilisés dans des déploiements réels.

• Possibilité de remplacer les combinaisons matériel/logiciel temps réel

  • Questionnement sur la possibilité de remplacer des combinaisons matériel/logiciel nécessitant du temps réel par des puces ARM et x86 bon marché, sobres en énergie et à haute fréquence.
  • Il est mentionné qu’à mesure que la fréquence d’horloge augmente, l’importance d’un temps réel parfait peut diminuer.

• Distinction entre applications temps réel « dur » et « souple »

  • Pour les applications temps réel « dur », il est préférable de ne pas utiliser un OS généraliste comme Linux.
  • Pour les applications temps réel « souple » (par ex. visioconférence, lecture audio), un peu de latence ou quelques pertes de frames ne posent pas de gros problèmes.
  • Les discussions visant à faire de Linux un OS temps réel se concentrent sur des cas d’usage temps réel « souple » déjà possibles.
  • Rendre le noyau entièrement préemptible et mieux contrôler l’ordonnancement a davantage de sens pour une gestion saine du système que pour remplacer un OS temps réel ou du code bare metal.

• Le traitement temps réel du noyau Linux et les limites du matériel

  • Même si le noyau Linux prend en charge le temps réel, le matériel peut ne pas le permettre à cause des caches et des fonctions complexes internes au CPU.
  • Pour un véritable temps réel, on préfère souvent des architectures CPU simples plutôt qu’un matériel complexe.

• Les problèmes de la journalisation synchrone

  • Expérience de blocage sur les E/S disque avec une journalisation synchrone comme GLOG (la bibliothèque de logs de Google), provoquant des retards de service.

• Comment garantir la réactivité d’un processus spécifique

  • Si la réactivité d’un processus donné est critique, il faut lui allouer un cœur CPU dédié et une zone mémoire contiguë, ainsi qu’un accès direct à une carte réseau isolée du reste de l’OS.

• La préemption temps réel de Linux et une expérience passée

  • Partage d’une expérience passée consistant à appliquer le patch RT_PREEMPT au noyau Linux pour l’utiliser avec des instruments scientifiques, avec de bonnes améliorations de latence et de gigue.

• Impact pour les utilisateurs ordinaires

  • Question sur ce que les capacités temps réel signifient pour les utilisateurs ordinaires, sur le fait de savoir si elles ne seraient activées que dans certains cas, et sur leur capacité à améliorer aussi la réactivité générale du système.