solutions temps réel sous linux
Post on 12-Apr-2017
158 Views
Preview:
TRANSCRIPT
1Meetup LE Bordeaux
Solutions temps réel sous Linux
PREEMPT-RT et Xenomai
Pierre Ficheux (pierre.ficheux@openwide.fr)
Octobre 2016
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
3Meetup LE Bordeaux
Le petit dernier !
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)
5Meetup LE Bordeaux
BB Black (Cortex-A8), timer 1 ms
6Meetup LE Bordeaux
Raspberry Pi, timer 1 ms
7Meetup LE Bordeaux
Idem avec SCHED_FIFO
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
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
10Meetup LE Bordeaux
Configuration PREEMPT-RT
HRTIMER
IRQ = kernel thread
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
12Meetup LE Bordeaux
x86 + PREEMPT-RT
13Meetup LE Bordeaux
Raspberry Pi + PREEMPT-RT
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)
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
16Meetup LE Bordeaux
Architecture initiale RTLinux
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
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)
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 !
20Meetup LE Bordeaux
RTLinux sur x86 (2002)
21Meetup LE Bordeaux
BB Black Xenomai (2013)
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 TRProcessus Linux
23Meetup LE Bordeaux
Architecture 3.0 (double noyau)
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
25Meetup LE Bordeaux
Répartition sur les deux domaines
Hardware
VFS/FS ...
Pile réseau Xenomai RTOS
Adeos I-Pipe
Noyau
Code applicatif VxWorks
glibcXenomailibvxworks
Code applicatif POSIX
Xenomailibpthread
Appels système
glibc
libpthread_rt
Noyau Linux
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)
27Meetup LE Bordeaux
Configuration du noyau
● Nouvelle entrée Real-time sub-system dans le menu de configuration → make menuconfig
28Meetup LE Bordeaux
Configuration du noyau, suite
sélection « statique »
spécificités matérielles« skins »
incompatibilité de config
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
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
31Meetup LE Bordeaux
Schéma fonctionnel I-pipe
Priorité topmost
Événements (IRQ, etc.)
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
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()
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()
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
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.)
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
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
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)
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.
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
top related