![9Meetup LE Bordeaux
Modifications apportées
● Threaded interrupt model → utilisation d'un thread
noyau (interruptible) pour le traitement de chaque
interruption
4 2 root SW< 0 0% 0% [sirq-high/0]
5 2 root SW< 0 0% 0% [sirq-timer/0]
6 2 root SW< 0 0% 0% [sirq-net-tx/0]
● Prévention des inversions de priorité (par héritage)
● Timer noyau haute précision (hrtimer)
● Réécriture complète des mécanismes de
synchronisation (spinlock → mutex)
● Compatibilité avec Ftrace pour la mise au point
→ La quasi-totalité du noyau est « preemptible », mais
reste un noyau Linux](https://image.slidesharecdn.com/linuxembarquebx-161019082101/85/Solutions-temps-reel-sous-linux-9-320.jpg)
Solutions temps réel sous linux
- 1. 1Meetup LE Bordeaux Solutions temps réel sous Linux PREEMPT-RT et Xenomai Pierre Ficheux ([email protected]) Octobre 2016
- 2. 2Meetup LE Bordeaux Présentation PF ● CTO Open Wide Ingénierie, enseignant EPITA, etc. ● Responsable spécialité GISTRE à l'EPITA ● Auteur des 4 éditions de l'ouvrage « Linux embarqué » (Eyrolles), 4ème édition parue en juin 2012 avec E. Bénard ● LB « Linux pour l'embarqué » (Smile) ● Rédacteur en chef d' Open Silicium
- 3. 3Meetup LE Bordeaux Le petit dernier !
- 4. 4Meetup LE Bordeaux Linux « standard » ● Pas de préemption « complète » en mode noyau → un processus ne peut être interrompu dans une routine de traitement d’interruption ● Préemption par l'ordonnanceur – Si période fixe (constante HZ = nombre de ticks par seconde = 1000) → précision de l'ordonnanceur (granularité) – Option « tickless », améliore la consommation mais pas le TR → problème de réveil du CPU ● Ordonnancement par niveau de priorité (POSIX) – Priorité dynamique standard (0, ajustable avec « nice ») → SCHED_OTHER – Priorité statique « temps réel » SCHED_FIFO/RR (1 à 99)
- 5. 5Meetup LE Bordeaux BB Black (Cortex-A8), timer 1 ms
- 6. 6Meetup LE Bordeaux Raspberry Pi, timer 1 ms
- 7. 7Meetup LE Bordeaux Idem avec SCHED_FIFO
- 8. 8Meetup LE Bordeaux PREEMPT-RT ● Branche expérimentale pour le noyau 2.6 ● Initié par Ingo Molnar ● Maintenu par Thomas Gleixner ● Adopté par la fondation Linux en octobre 2015 ● Surtout utilisé sur x86 et des processeurs performants (TSC = Time Stamp Counter) ● Fonctionne également sur ARM (9 ou plus), Nios II, Microblaze, etc. ● Nécessite un noyau « mainline » (ou proche) ● Mise en place très simple (application d'un patch) ● Mêmes API de programmation que Linux standard
- 9. 9Meetup LE Bordeaux Modifications apportées ● Threaded interrupt model → utilisation d'un thread noyau (interruptible) pour le traitement de chaque interruption 4 2 root SW< 0 0% 0% [sirq-high/0] 5 2 root SW< 0 0% 0% [sirq-timer/0] 6 2 root SW< 0 0% 0% [sirq-net-tx/0] ● Prévention des inversions de priorité (par héritage) ● Timer noyau haute précision (hrtimer) ● Réécriture complète des mécanismes de synchronisation (spinlock → mutex) ● Compatibilité avec Ftrace pour la mise au point → La quasi-totalité du noyau est « preemptible », mais reste un noyau Linux
- 10. 10Meetup LE Bordeaux Configuration PREEMPT-RT HRTIMER IRQ = kernel thread
- 11. 11Meetup LE Bordeaux Mesures de performances ● Utilisation du programme cyclictest avec 5 threads temps réel (période = 1 ms) + appel système nanosleep() # cyclictest -p 99 -t 5 -n ● Charge avec hackbench (création de 800 tâches communiquant entre eux par pipe) # hackbench -p -g 20 -l 1000 ● Tests sur Atom/x86 (N550) et Raspberry Pi B+ – jitter avec noyau standard = plusieurs ms ! – jitter avec PREEMPT-RT < 50 µs :-) – jitter sur Rasperry Pi < 150 µs
- 12. 12Meetup LE Bordeaux x86 + PREEMPT-RT
- 13. 13Meetup LE Bordeaux Raspberry Pi + PREEMPT-RT
- 14. 14Meetup LE Bordeaux Linux + co-noyau ● Méthode plus complexe mais plus efficace ● Séparation entre le noyau temps-réel et Linux – Ordonnanceur temps-réel spécifique – Pas de « sections critiques » avec Linux ● Virtualisation de la gestion d'interruptions Linux – Routage prioritaire des IRQ vers le co-noyau ● Linux comme tâche « idle » du co-noyau ● Se rapproche de la technique de « para-virtualisation » des hyperviseurs (adaptation de l'OS)
- 15. 15Meetup LE Bordeaux RTLinux ● Projet universitaire (NMT) développé par Victor Yodaiken et Michael Barabanov en 1999 ● Produit commercial développé par FSMLabs ● Dépôt d’un brevet logiciel → conflit avec la FSF ● Vendu à WIND RIVER en 2007 ● Développement en espace noyau (?) ● Version GPL obsolète (2.6.9) retirée par WIND RIVER
- 16. 16Meetup LE Bordeaux Architecture initiale RTLinux
- 17. 17Meetup LE Bordeaux RTAI ● Real Time Application Interface ● Un « fork » de RTLinux développé au DIAPM de l’école polytechnique de Milan → Dipartimento di Ingegneria Aerospaziale (Paolo Montegazza) ● Utilisé au DIAPM pour des travaux d’enseignement et de recherche ● Position douteuse / brevet logiciel FSMLabs ● Collaboration avec Xenomai entre 2003 et 2005 → RTAI/Fusion ● Version 3.8 en février 2010, 3.9 en août 2012, 4.0 en décembre 2013, 5.0 en décembre 2015
- 18. 18Meetup LE Bordeaux Xenomai ● Autrefois lié à RTAI ● Indépendant depuis 2005 ● Développement de tâches temps réel en espace utilisateur :-) ● API de pilotes noyau → RTDM (Real Time Driver Model) ● Projet Linux/TR le plus avancé (et performant) à ce jour ● Désormais deux versions – 2.6.x (maintenance) – 3.0.3 (officielle)
- 19. 19Meetup LE Bordeaux Utilisation et performances ● Changement minimal sur le noyau Linux – patch de virtualisation d'interruptions – pas d'impact sur l'écriture de code noyau classique ● Impact sur l'écriture de code temps-réel ! – utilisation d'APIs fournies par le co-noyau – notion de domaine d'exécution (temps-réel ou Linux) ● Garanties temps-réel fortes – ordonnanceur spécifique indépendant – sous-système temps-réel bien délimité – Avec Xenomai ou RTAI, gigue maximale de l’ordre de 10 µs sur Atom N550, 50 µs sur RPi !
- 20. 20Meetup LE Bordeaux RTLinux sur x86 (2002)
- 21. 21Meetup LE Bordeaux BB Black Xenomai (2013)
- 22. 22Meetup LE Bordeaux Architecture générale ● Xenomai utilise un « hyperviseur » (ADEOS/I-pipe) pour partager le matériel avec le noyau Linux ● Un processus contient des threads TR et TP (Linux) « hyperviseur » noyau TR API TR pilote TR Processus Linux
- 23. 23Meetup LE Bordeaux Architecture 3.0 (double noyau)
- 24. 24Meetup LE Bordeaux Architecture générale, suite ● Adaptabilité – cœur de RTOS générique → « nucleus » (Cobalt en 3.0) – spécialisation d'interfaces ou skins (souvent POSIX) ● Modèle de programmation – espace noyau → le plus souvent pour les pilotes RTDM – espace utilisateur standard par les « skins » – L'application Linux est répartie sur les deux noyaux (Linux et Xenomai) ou « domaines » ● Couches d'abstraction d'architecture hôte SAL/HAL – rassemble les dépendances matérielles de la cible ● Multi plates-formes – arm, blackfin, i386, ia64, powerpc32, powerpc64, nios2, sh4
- 25. 25Meetup LE Bordeaux Répartition sur les deux domaines Hardware VFS/FS ... Pile réseau Xenomai RTOS Adeos I-Pipe Noyau Code applicatif VxWorks glibc Xenomai libvxworks Code applicatif POSIX Xenomai libpthread Appels système glibc libpthread_rt Noyau Linux
- 26. 26Meetup LE Bordeaux Installation ● Téléchargement des sources – noyau Linux officiel – Xenomai ● Préparation des sources noyau – patch Adeos/I-pipe – intégration du code Xenomai (prepare-kernel.sh) ● Configuration, compilation, installation du noyau ● Configuration, compilation, installation des bibliothèques et utilitaires de Xenomai (espace utilisateur) → Autotools ● Redémarrage et test avec latency ● Intégré à Builroot ● Couche « meta-xenomai » (Yocto)
- 27. 27Meetup LE Bordeaux Configuration du noyau ● Nouvelle entrée Real-time sub-system dans le menu de configuration → make menuconfig
- 28. 28Meetup LE Bordeaux Configuration du noyau, suite sélection « statique » spécificités matérielles « skins » incompatibilité de config
- 29. 29Meetup LE Bordeaux Anticipation des latences ● Anticipation de la durée entre IT matérielle et traitement ● Déclenchement du compteur en avance ● Valeur statique dans /proc/xenomai/latency ● Optisation de la valeur # echo 0 > /proc/xenomai/latency # latency ... ● On remplace par la valeur « latency best » obtenue # echo 2000 > /proc/xenomai/latency ● Au prochain test la valeur « latency best » devient donc 0
- 30. 30Meetup LE Bordeaux I-pipe (ADEOS) ● Adaptative Domain Environment for Operating Systems ● Proposé par Karim Yaghmour en 2002 ● Virtualisation de ressources matérielles →cohabitation de plusieurs noyaux sur une même machine ● Basé sur un « pipeline d'interruptions » (I-pipe) ● Organisation en domaines avec priorité (topmost pour Xenomai) – Composant logiciel basé sur un micro-noyau – Notifié par ADEOS lors d'événements (interruption, trappe, appel système, ...) ● Existe uniquement sous la forme d'un « patch » pour le noyau Linux
- 31. 31Meetup LE Bordeaux Schéma fonctionnel I-pipe Priorité topmost Événements (IRQ, etc.)
- 32. 32Meetup LE Bordeaux Principe du I-pipe ● Le I-pipe est démarré par le domaine « racine » (Linux) dans start_kernel() ● Le contrôleur d'interruption matériel est remplacé par un contrôle logiciel → I-pipe (ADEOS) ● Seul I-pipe a le contrôle matériel des IRQ externes ● Évite le masquage physique des IRQ qui bloquerait les tâches TR ● Blocage/déblocage du domaine racine (stall/unstall) ● Les IRQ TR sont traitées en priorité dans I-pipe ● Pour chaque interruption, le domaine peut : – Accepter → traitement immédiat – Ignorer → différée (blocage du domaine racine) – Écarter → propagée au domaine suivant – Terminer → non propagée
- 33. 33Meetup LE Bordeaux Blocage du domaine racine (stall) ● On diffère le traitement de l'IRQ en « bloquant » le domaine mais pas la réception d'IRQ (et donc le traitement d'IRQ TR) ● Les IRQ reçues sont stockées dans le tampon « i-log » ● Utilise la fonction ipipe_stall_root()
- 34. 34Meetup LE Bordeaux Déblocage du domaine (unstall) ● Le domaine racine demande le déblocage dès qu'il peut à nouveau traiter des IRQ ● On vide le contenu du tampon « i-log » ● Utilise la fonction ipipe_unstall_root()
- 35. 35Meetup LE Bordeaux Compteur TSC + Xenomai ● Le TSC (Time Stamp Counter) est disponible sur l'architecture x86 ● Nombre de cycles depuis reset (64 bits) ● Base de temps très précise ● Option visible dans /proc/cpuinfo ● Utilisé dans PREEMPT-RT ● Le TSC doit être émulé sur ARM par un compteur # cat /proc/xenomai/timer ...:clockdev=ipipe_tsc ● Chaque fondeur implémente différemment le compteur matériel → nécessité du patch I-pipe
- 36. 36Meetup LE Bordeaux Domaines d'exécution ● Ordonnancement sur les 2 domaines – Domaine Xenomai, déterministe – Domaine Linux, non déterministe ● Exécution d'une tâche temps-réel – Mode primaire (domaine Xenomai) – Mode secondaire (domaine Linux) ● Migration de modes (sur appel système, etc.)
- 37. 37Meetup LE Bordeaux Interface native ● Interface temps-réel classique – tâches → rt_task_create(), rt_task_start() – tâches périodiques→ rt_task_set_periodic() – timers – mutexes, variables condition – sémaphores, groupes d'événements – files de messages, mémoire partagée – régions de mémoire – FIFO intra et inter-domaines (message pipes) → déprécié ● Proche de RTAI ● Non portable
- 38. 38Meetup LE Bordeaux Interface POSIX ● Convergence POSIX 1003.1b/1c – pthread – horloge et compteur – mutex, condition, sémaphore – files de messages – mémoire partagée – quelques extensions (suffixe _np) ● tâche périodique, ● migration de mode – signaux ● Utilisé conjointement avec la version Linux -lpthread -lpthread_rt
- 39. 39Meetup LE Bordeaux RTDM ● Real Time Driver Model → « skin » RTDM ● Développement de pilote noyau TR → extension de l'API Linux ● Un pilote RTDM est un module Linux (.ko) ● Programmation possible de tâches TR ● Deux types des pilotes – Named device → pilote mode caractère – Protocol device → pilote réseau ● Communication « inter-domaine » (XDDP) – /dev/rtpX coté Linux (non TR) – Port UDP numéro X coté Xenomai (TR)
- 40. 40Meetup LE Bordeaux Spécificité des appels système ● Utilisation du suffixe _rt ou _nrt pour les fonctions du pilote (open, close, read, write, bind, connect, ...) – fn_rt() si appel en contexte temps réel – fn_nrt() si appel en contexte Linux ● En pratique : – open_nrt() et close_nrt() car appelées depuis le domaine Linux – Les autres fonctions dans le domaine temps réel: read_rt(), write_rt(), etc. ● Appel depuis l'applicatif par : rt_dev_open(), rt_dev_write(), rt_dev_read(), etc.
- 41. 41Meetup LE Bordeaux Bibliographie ● http://www.linuxjournal.com/article/5600 ● https://www.quora.com/What-is-a-tickless-kernel ● http://www.eyrolles.com/Informatique/Livre/solutions-temps-reel-sous-linux-9782212142082 ● http://rt.wiki.kernel.org ● http://www.rtai.org ● http://www.xenomai.org ● http://www.blaess.fr/christophe/livres/solutions-temps-reel-sous-linux ● http://francois.touchard.perso.luminy.univ-amu.fr/3/LinuxAvance/C1-intro.pdf ● http://francois.touchard.perso.luminy.univ-amu.fr/3/LinuxAvance/C4-RTDM.pdf ● http://xenomai.org/2014/06/porting-a-posix-application-to-xenomai ● http://www.xenomai.org/documentation/trunk/html/api ● http://www.xenomai.org/documentation/xenomai-2.3/pdf/Life-with-Adeos-rev-B.pdf ● http://xenomai.org/2014/06/using-the-i-pipe-tracer ● http://www.blaess.fr/christophe/2012/07/23/les-latences-de-xenomai ● http://www.xenomai.org/documentation/trunk/html/api/group__rtdmtask.html ● http://fr.slideshare.net/jserv/realtime-linux