Le document présente des solutions pour le temps réel sous Linux, notamment avec les projets Preempt-RT et Xenomai. Il aborde les modifications apportées au noyau Linux pour améliorer la préemption et preemptability, et décrit l'architecture et l'utilisation de ces systèmes en temps réel. Les performances sont mesurées avec des exemples pratiques démontrant des réductions significatives de jitter par rapport aux versions standard du noyau.

1. 1Meetup LE Bordeaux
Solutions temps réel sous Linux
PREEMPT-RT et Xenomai
Pierre Ficheux (pierre.ficheux@openwide.fr)
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