13 points par GN⁺ 2024-09-20 | 4 commentaires | Partager sur WhatsApp
  • Realtime Linux est désormais officiellement intégré au noyau, ce qui permet d’utiliser un « Linux temps réel » sans système d’exploitation temps réel (RTOS) distinct
  • Si vous vouliez utiliser un « Linux temps réel » pour des équipements audio, des lasers de soudage industriels ou des rovers martiens, cette option existait depuis longtemps (à supposer de ne pas choisir des alternatives comme QNX)
  • Des universités ont commencé à développer leurs propres noyaux temps réel à partir de la fin des années 1990
  • Un ensemble de correctifs appelé PREEMPT_RT existe au moins depuis 2005
  • Certains aspects des charges de travail temps réel, comme NO_HZ, avaient déjà été intégrés au noyau principal il y a longtemps, ce qui les a rendus utilisables dans les data centers, le cloud computing et, plus largement, sur tout système doté de nombreux CPU

Fusion de PREEMPT_RT dans la branche principale

  • PREEMPT_RT a de fortes chances d’être fusionné dans la branche principale avec le noyau 6.12
  • L’approbation finale a été donnée pendant la participation de Linus Torvalds à l’Open Source Summit Europe
  • Torvalds a écrit le code d’origine de printk, un outil de débogage capable d’identifier le moment exact où un processus se bloque, mais qui introduit une latence contraire aux exigences du calcul temps réel
  • Le blog Phoronix a suivi l’avancement de PREEMPT_RT vers le noyau, ainsi que les modifications de printk nécessaires à la prise en charge thread/atomic console, essentielle à cette intégration temps réel

Quel impact sur Linux de bureau ? Très peu

  • En dehors de la production ou de la restitution audio avancée — et même cela reste sujet à débat — un noyau temps réel ne rendra ni les fenêtres ni les programmes plus rapides
  • En revanche, l’exécution garantie et la latence dans le pire des cas offertes par Linux temps réel sont très utiles pour les systèmes qui surveillent les freins automobiles, pilotent des machines CNC ou régulent des systèmes complexes à plusieurs CPU
  • L’inclusion de PREEMPT-RT dans le noyau principal facilitera la maintenance des systèmes temps réel, puisqu’il ne sera plus nécessaire de gérer des correctifs hors arbre

Impact sur les fournisseurs spécialisés de solutions OS temps réel

  • Ubuntu a commencé à proposer en 2023 une version temps réel de sa distribution, mais elle nécessitait un abonnement Ubuntu Pro
  • Ubuntu fournissait cette version temps réel avec des ajustements, correctifs, intégration de modules et tests pour la robotique, l’automatisation, l’embarqué Linux et d’autres besoins temps réel
  • La situation devrait désormais évoluer pour les fournisseurs spécialisés de solutions OS temps réel destinées aux systèmes critiques

Le point de vue de Linus Torvalds

  • Lors du Kernel Summit 2006, Torvalds avait déclaré : « Contrôler un laser avec Linux, c’est de la folie, mais dans cette salle, tout le monde est fou à sa manière »
  • Il avait aussi affirmé : « Si vous voulez utiliser Linux pour contrôler un laser de soudage industriel, je n’ai aucun problème avec l’utilisation de PREEMPT_RT »
  • Environ 18 ans plus tard, Torvalds, l’équipe du noyau et Steven Rostedt, mainteneur historique et grand défenseur du temps réel, ont rendu ce type d’usage plus simple

Avis de GN⁺

  • L’intégration de Linux temps réel dans la branche principale devrait encore élargir le champ d’application de Linux et permettre son usage dans davantage de domaines
  • Linux devrait être encore plus largement utilisé, en particulier dans les environnements industriels, les systèmes embarqués et la robotique, où les contraintes temps réel sont essentielles
  • Cela dit, l’adoption de Linux temps réel devra tenir compte de la compatibilité matérielle, de la stabilité du système et de la complexité du développement
  • Les OS temps réel existants comme QNX, VxWorks et INTEGRITY resteront compétitifs dans leurs domaines respectifs, et le choix devra se faire selon le contexte
  • À mesure que Linux temps réel rejoint la branche principale, on peut s’attendre à un écosystème de développement plus dynamique et à une prise en charge plus large de matériels et logiciels variés

4 commentaires

 
ilotoki0804 2024-09-23

J’aurais aimé qu’il y ait au moins une brève explication de ce qu’est un système d’exploitation temps réel, de ce qu’est PREEMPT_RT et de son lien avec un système d’exploitation temps réel, mais c’est dommage qu’il n’y ait presque aucun détail, snif.

 
tongji 2024-09-23

La principale différence entre Linux et un Real-Time Operating System (RTOS) réside dans le comportement temps réel et le déterminisme. Cette différence a un impact majeur sur les contraintes de temps de réponse et la précision du système, et aide à comprendre dans quels cas chaque OS est adapté.

  1. Aperçu de Linux et des RTOS
    Linux : système d’exploitation généralement basé sur un noyau Linux modifié, utilisé sur divers matériels embarqués. Convivial, il fournit de nombreuses fonctionnalités comme le réseau, le système de fichiers ou les pilotes, ce qui le rend adapté aux applications complexes.

RTOS (Real-Time Operating System) : système d’exploitation qui garantit une réactivité permettant de traiter les tâches dans un délai donné. Les RTOS sont principalement utilisés dans des domaines où la réponse en temps réel est essentielle, comme l’automatisation industrielle, les équipements médicaux ou les systèmes de contrôle automobile.

  1. Différences en matière de temps réel et de comportement déterministe
    Caractéristiques de Linux
    Temps de réponse non déterministe : le noyau Linux est conçu avant tout pour le throughput et l’efficacité, il est donc impossible de prévoir avec précision quand une tâche sera exécutée. Cela s’explique par le fait que l’ordonnanceur gère des tâches de priorités variées, et que des processus complexes comme les opérations d’I/O ou la gestion mémoire influencent l’exécution.

Limites de la preemption : un noyau Linux classique offre certaines fonctions temps réel, mais toutes les opérations du noyau ne peuvent pas être interrompues immédiatement. En particulier, le noyau peut parfois ne pas réagir aux interruptions pendant une longue période, ou retarder d’autres tâches parce qu’il exécute un travail critique.

Variabilité de la latence : dans un environnement multitâche avec de nombreuses opérations système, la latence peut varier de manière irrégulière. Elle peut être affectée par divers éléments comme le traitement de la pile réseau ou les I/O disque.

Patch temps réel (PREEMPT-RT) : pour améliorer la réponse temps réel, il est possible d’appliquer le patch PREEMPT-RT afin d’augmenter les capacités temps réel du noyau. Cela ne garantit toutefois pas des réponses aussi parfaitement prévisibles qu’avec un RTOS.

Caractéristiques des RTOS
Temps de réponse déterministe : par conception, un RTOS garantit qu’une tâche peut être terminée dans un délai précis. Comme l’exécution doit impérativement avoir lieu dans le temps imparti, la réponse est très cohérente et prévisible.

Traitement rapide des interruptions : un RTOS traite les interruptions rapidement et en priorité, et dans la plupart des cas les privilégie afin que les tâches critiques soient exécutées sans délai. Cela permet de respecter des contraintes hard real-time.

Noyau réduit et léger : un RTOS n’inclut que le strict nécessaire, ce qui le rend très léger, avec une planification des tâches très efficace. La charge système reste donc faible et les tâches peuvent être exécutées selon un timing précisément défini.

Ordonnancement basé sur les priorités : les priorités des tâches sont définies clairement, et les travaux les plus prioritaires peuvent être traités immédiatement. Cela garantit son usage dans des environnements mission-critical.

Low latency : un RTOS traite les tâches temps réel avec une latence très faible. Il est adapté lorsqu’une réponse rapide au niveau matériel est nécessaire.

  1. Résumé des principales différences du point de vue temps réel
    Caractéristique || Linux RTOS
    ============================================================
    Temps de réponse || non déterministe, variable déterministe, temps de réponse constant garanti
    Gestion des priorités || priorités présentes, mais sans garantie temps réel priorités clairement définies,
    || traitement prioritaire des tâches les plus importantes
    Taille du noyau || grande, riche en fonctionnalités petite et légère
    Latence || peut être retardée par le réseau, les I/O disque, etc. très faible, presque constante

Complexité système || adaptée à l’exécution d’applications complexes adaptée à l’exécution de tâches temps réel simples
Domaines d’application || multimédia, réseau, etc. contrôle industriel, robotique, dispositifs médicaux, etc.
|| interfaces utilisateur complexes
Conclusion
Embedded Linux convient aux systèmes embarqués qui nécessitent du traitement réseau, des applications multimédia et des interfaces utilisateur complexes. L’application d’un patch temps réel permet d’améliorer dans une certaine mesure les performances temps réel, mais le système reste moins déterministe qu’un RTOS.

Un RTOS est indispensable pour les applications mission-critical où le temps est un facteur clé. Lorsqu’un temps de réponse constant est requis, notamment dans des environnements soumis à des contraintes temps réel comme le contrôle matériel, la robotique industrielle, l’aérospatial ou les équipements médicaux, on utilise un RTOS.

 
helloppfm 2024-09-22

J’ai toujours eu du mal à cause de QNX et de VxWorks, mais désormais tout le monde pourra y accéder un peu plus facilement.

 
GN⁺ 2024-09-20
Commentaires Hacker News
  • C’est l’aboutissement d’un gros travail après des années d’efforts

    • L’essentiel du travail a été réalisé par Thomas Gleixner et son équipe
    • Il a fondé Linutronix, désormais détenue par Intel
    • Fournit un lien vers la pull request concernant la dernière partie de printk
    • Fournit un lien vers la pull request pour PREEMPT_RT dans la configuration du noyau
    • Fournit un lien vers le journal des patchs RT au-dessus du noyau v6.11
    • La nouvelle infrastructure printk doit encore être adoptée par de vrais pilotes
    • La taille du patchset RT est devenue bien plus petite qu’auparavant
    • C’est un signal fort de confiance de la part de Linus
    • Félicitations à l’équipe
  • Pour constater l’effet d’un noyau temps réel, il est recommandé de compiler et d’exécuter l’utilitaire cyclictest

    • Il mesure et affiche la latence des interruptions sur chaque cœur CPU
    • Sans patch temps réel, la latence dans le pire des cas peut atteindre des dizaines de millisecondes
    • Avec le patch temps réel appliqué, la latence dans le pire des cas tombe à un chiffre en microsecondes
    • Pour obtenir une latence faible et régulière, il faut désactiver les états d’économie d’énergie
    • cyclictest est un outil important pour travailler en temps réel sous Linux
    • Explique la différence de performances du système lors du traitement de radio logicielle (SDR)
    • Avec un noyau temps réel, le SDR fonctionne sans problème même en lançant GNOME et LibreOffice
  • Sans le patchset RT, on peut faire tourner un ou deux instruments avec une latence de 3 ms

    • Avec le patchset RT, on peut faire tourner 6 instruments avec une latence de 1 ms
    • Aucun problème même avec des dizaines de fenêtres Chrome ouvertes et un jeu de tir 3D en cours
    • La différence est importante par rapport à un simple ordonnanceur basse latence
  • Partage une expérience où Linux a été utilisé pour du temps réel au milieu des années 2000

    • À l’époque, le Linux temps réel était très bricolé et hors arbre
    • Une solution courante consistait à héberger Linux comme processus à l’intérieur d’un véritable micro-noyau temps réel afin d’obtenir un comportement temps réel
    • Si le Linux temps réel était peu pratique, c’est parce qu’il fallait garantir le temps d’exécution de toutes les sections non préemptibles
    • Se demande comment cette exigence a été résolue
    • Demande si Linux prend en charge l’inversion de priorité
  • Demande s’il existe de bonnes ressources sur la manière de faire de la programmation temps réel

    • Se demande comment vérifier qu’un programme est réellement temps réel
    • Demande si le code temps réel diffère du code classique
    • S’interroge sur l’impact des architectures CPU modernes sur la programmation temps réel
  • Met en doute la mention selon laquelle Torvalds aurait écrit le code original de printk

    • N’est pas d’accord avec l’explication donnée au sujet de l’outil de débogage printk
  • Cela sera d’une grande aide pour la communauté CNC

    • Le RT est indispensable et rend les builds beaucoup plus faciles
  • Trouve cela très cool

    • Se demande comment on l’« active »
    • Demande s’il s’agit d’une option à la compilation / au démarrage, ou si un processus en cours d’exécution sur le système peut demander une garantie de tranche de temps / de latence
  • S’interroge sur les inconvénients de l’utilisation d’un noyau temps réel pour les utilisateurs desktop