solutions temps réel sous linux

41
1 Meetup LE Bordeaux Solutions temps réel sous Linux PREEMPT-RT et Xenomai Pierre Ficheux ([email protected]) Octobre 2016

Upload: embedded-linux-bdx

Post on 12-Apr-2017

138 views

Category:

Engineering


3 download

TRANSCRIPT

Page 1: Solutions temps réel sous linux

1Meetup LE Bordeaux

Solutions temps réel sous Linux

PREEMPT-RT et Xenomai

Pierre Ficheux ([email protected])

Octobre 2016

Page 2: Solutions temps réel sous linux

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

Page 3: Solutions temps réel sous linux

3Meetup LE Bordeaux

Le petit dernier !

Page 4: Solutions temps réel sous linux

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)

Page 5: Solutions temps réel sous linux

5Meetup LE Bordeaux

BB Black (Cortex-A8), timer 1 ms

Page 6: Solutions temps réel sous linux

6Meetup LE Bordeaux

Raspberry Pi, timer 1 ms

Page 7: Solutions temps réel sous linux

7Meetup LE Bordeaux

Idem avec SCHED_FIFO

Page 8: Solutions temps réel sous linux

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

Page 9: Solutions temps réel sous linux

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

Page 10: Solutions temps réel sous linux

10Meetup LE Bordeaux

Configuration PREEMPT-RT

HRTIMER

IRQ = kernel thread

Page 11: Solutions temps réel sous linux

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

Page 12: Solutions temps réel sous linux

12Meetup LE Bordeaux

x86 + PREEMPT-RT

Page 13: Solutions temps réel sous linux

13Meetup LE Bordeaux

Raspberry Pi + PREEMPT-RT

Page 14: Solutions temps réel sous linux

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)

Page 15: Solutions temps réel sous linux

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

Page 16: Solutions temps réel sous linux

16Meetup LE Bordeaux

Architecture initiale RTLinux

Page 17: Solutions temps réel sous linux

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

Page 18: Solutions temps réel sous linux

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)

Page 19: Solutions temps réel sous linux

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 !

Page 20: Solutions temps réel sous linux

20Meetup LE Bordeaux

RTLinux sur x86 (2002)

Page 21: Solutions temps réel sous linux

21Meetup LE Bordeaux

BB Black Xenomai (2013)

Page 22: Solutions temps réel sous linux

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

Page 23: Solutions temps réel sous linux

23Meetup LE Bordeaux

Architecture 3.0 (double noyau)

Page 24: Solutions temps réel sous linux

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

Page 25: Solutions temps réel sous linux

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

Page 26: Solutions temps réel sous 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)

Page 27: Solutions temps réel sous linux

27Meetup LE Bordeaux

Configuration du noyau

● Nouvelle entrée Real-time sub-system dans le menu de configuration → make menuconfig

Page 28: Solutions temps réel sous linux

28Meetup LE Bordeaux

Configuration du noyau, suite

sélection « statique »

spécificités matérielles« skins »

incompatibilité de config

Page 29: Solutions temps réel sous linux

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

Page 30: Solutions temps réel sous linux

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

Page 31: Solutions temps réel sous linux

31Meetup LE Bordeaux

Schéma fonctionnel I-pipe

Priorité topmost

Événements (IRQ, etc.)

Page 32: Solutions temps réel sous linux

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

Page 33: Solutions temps réel sous linux

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()

Page 34: Solutions temps réel sous linux

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()

Page 35: Solutions temps réel sous linux

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

Page 36: Solutions temps réel sous linux

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.)

Page 37: Solutions temps réel sous linux

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

Page 38: Solutions temps réel sous linux

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

Page 39: Solutions temps réel sous linux

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)

Page 40: Solutions temps réel sous linux

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.

Page 41: Solutions temps réel sous linux

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