Linux™ est une implémentation complète de UNIX™.
C'est un Système dédié au temps partagé qui possède les
bases pour l'implémentation d'un executif temps réel
Linux et temps réel
Les systèmes UNIX™ moderne proposent un scheduleur offrant la
possibilité d'executer des tâches dites temps réel.
En réalité, ces tâches ne sont qualifiées de temps réel que par le fait
que le scheduleur du système d'exploitation les traite avec une grande priorité
ce qui leur permet de prendre la place d'une tâche de moindre priorité
immédiatement.
C'est une base mais il reste plusieurs points à améliorer pour
obtenir un véritable OS temps réel.
Le handicap principal de tout UNIX et de Linux en particulier, pour
devenir un executif temps réel vient du fait que le noyau n'est pas
préemptible.
Autrement dit, lorsqu'un process execute un appel système, ou lorsqu'une
interruption est executée, aucun autre process ou thread ne pourra
être executé.
Ce choix de construction initial peut être contourner en modifiant
l'architecture de Linux deux façons:
La première méthode est employée par
Timesys
et
Montevista
La seconde methode est utilisée par
RTLinux.
Les deux méthodes sont utilisées conjointement par
OCERA.
Amélioration de la préemption
Lorsque l'on veut executer un process temps réel sous Linux,
il est nécessaire de réduire le temps de latence lié à l'architecture
du noyau Linux.
Le temps de latence est defini comme le temps qui s'écoule entre le
moment ou une tâche est choisie pour être executée par le scheduleur
et le moment ou elle est réellement executée.
La plus grande source de latence sont les parties non préemptibles
du noyau: les Bottom Halfs et Interrupt Service Routines
des drivers et les appels système.
Ces sections non préemptibles peuvent augmenter la latence d'une
centaine de milisecondes.
La longueur d'une section non préemptible dépends de la stratégie
que le noyau utilise pour garantir l'intégrité de ses structures
de données interne.
Le noyau Linux standard est construit sur une forme classique monolithique
qui interdit toute préemption à partir du moment ou une partie du noyau
est executée lors d'un appel système ou lorsqu'une interruption
est executée.
Lorsqu'un appel système est effectué, le process entre dans le noyau et
devient non préemptible. Si une interription intervient à ce moment,
une ISR de courte durée est executée, puis la main est rendue
à l'appel système, la partie Bottom Half de l'interruption étant
exécutée seulement lorsque l'appel système sera terminé.
De cette présentation on voit poindre deux types de solutions:
- Modifier le noyau afin d'y introduire des points
de préemption: c'est l'approche utilisée par RED Linux
avec le patch "Low-Latency".
- Modifier la façon dont le noyau protège ses structures de données
et rendre le noyau préemptible:
c'est l'approche utilisée par TimeSys qui utilise des Mutex
et MonteVista qui utilise des Spinlocks.
Alors que le patch de Montevista interdit la préemption lorsqu'un
spinlock est acquis, celui de TimeSys bloque la synchronisation.
Ces solutions peuvent être utilisées ensemble afin de réduire
le temps d'utilisation des spinlocks
à l'aide de point de re-scheduling.
Cette présentation est faite à partir de l'étude réalisée par
l'équipe de OCERA que vous retrouverez sous sa forme complète ici:
Etude RTOS de OCERA.
Les gains obtenus par ces méthodes sont assez importants, le temps
de latence, initialement avec un maximum de 100ms peut être déscendu
aux alentours de 10ms.
Ces solutions sont donc envisageables pour des systèmes temps
réel de video (typiquement 1/25s = 40ms) et d'audio.
Virtualisation des interruptions
Dans le chapitre précédant, nous avons vu comment descendre le temps
de latence du scheduleur sous Linux aux alentour de 10ms.
Ceci n'est cependant pas suffisant pour du temps réel industriel.
En effet, pour la robotique, la gestion d'un moteur
de voiture, le pilotage de fusées, il est nécessaire de réagir
beaucoup plus vite.
Une possibilité est d'écrire l'application temps réel dans le noyau
Linux, sous forme de driver, cette solution d'abord simple devient vite
très complexe si l'application temps réel est importante.
La solution est d'ajouter un veritable executif temps réel
au dessous du noyau Linux, ce nouvel executif proposant à Linux
une abstraction des interruptions.
C'est cette solution qui est proposée par RTLinux, RTAI et OCERA
(OCERA utilise RTLinux-GPL ou MARTE comme base).
Le noyau Linux est modifié afin de tenir compte du fait que
RTLinux lui présente ainsi un matériel virtuel, les instructions comme
sti et cli sont remplacées par des appels à des fonctions gérées
par RTLinux.
Au niveau de la gestion des interruptions, RTLinux remplace la table
d'interruption de Linux par la sienne
et redirige ensuite vers les ISR de Linux les interruptions qu'il
ne gère pas.
Les process temps réel sous RTLinux disposent d'un environement temps
réel complet type POSIX 1003.13
Les taches temps réel sous RTLinux ont un temps de latence de quelques
microsecondes.
|