Comment “temps réel” est Linux 2.6?

Vous pouvez obtenir la plupart de vos réponses sur le wiki et la FAQ de Real Time Linux.

Quelles sont les fonctionnalités en temps réel du kernel Linux 2.6?

Traditionnellement, le kernel Linux ne permet à un seul processus de préempter un autre que dans certaines circonstances:

• Lorsque le processeur exécute le code du mode utilisateur
• Lorsque le code du kernel retourne d’un appel système ou d’une interruption à l’espace utilisateur
• Lorsque le code de code du kernel bloque sur un mutex, ou cède explicitement le contrôle à un autre processus

Si le code du kernel est en cours d’exécution lorsqu’un événement nécessite un thread de haute priorité pour commencer à s’exécuter, le thread de haute priorité ne peut pas préempter le code du kernel en cours d’exécution jusqu’à ce que le code du kernel donne explicitement le contrôle. Dans le pire des cas, la latence pourrait être de plusieurs centaines de millisecondes ou plus.

L’option de configuration Linux 2.6 CONFIG_PREEMPT_VOLUNTARY introduit des vérifications aux causes les plus courantes des longues latences, de sorte que le kernel puisse volontairement céder le contrôle à une tâche de priorité supérieure en attente d’exécution. Cela peut être utile, mais bien que cela réduise les occurrences de longues latences (des centaines de millisecondes à potentiellement des secondes ou plus), cela ne les élimine pas. Cependant, contrairement à CONFIG_PREEMPT (voir ci-dessous), CONFIG_PREEMPT_VOLUNTARY a un impact beaucoup plus faible sur le débit global du système. (Comme toujours, il existe un compromis classique entre le rendement – l’efficacité globale du système – et la latence. Avec les processeurs plus rapides des systèmes modernes, il est souvent judicieux Les systèmes de classe qui n’ont pas besoin de garanties de latence minimales peuvent très bien choisir d’utiliser CONFIG_PREEMPT_VOLUNTARY ou de restr fidèle à la conception de kernel non préemptible traditionnelle.

Le kernel Linux 2.6 a une option de configuration supplémentaire, CONFIG_PREEMPT, qui permet à tous les codes du kernel situés en dehors des régions protégées par spinlock et aux gestionnaires d’interruptions d’être éligibles à la préemption par les threads de priorité supérieure. Avec cette option, la latence la plus défavorable tombe à (environ) millisecondes, bien que certains pilotes de périphériques puissent avoir des gestionnaires d’interruptions qui introduiront une latence bien pire. Si une application Linux en temps réel requirejs des latences inférieures à une milliseconde, l’utilisation du correctif CONFIG_PREEMPT_RT est fortement recommandée.

Ils ont aussi une liste de “Gotcha” comme vous les appelez dans la FAQ.

Quelles sont les choses importantes à garder à l’esprit lors de l’écriture d’applications en temps réel?

Prendre soin de ce qui suit pendant la phase de démarrage initiale:

• Appelez mlockall () dès que possible à partir de main ().
• Créez tous les threads au démarrage de l’application et touchez chaque page de la stack entière de chaque thread. Ne démarrez jamais les threads de manière dynamic pendant le temps d’affichage RT, cela va ruiner le comportement de RT.
• N’utilisez jamais d’appels système connus pour générer des défauts de page, tels que fopen (). (L’ouverture des fichiers appelle l’appel système mmap (), qui génère un défaut de page).
• Si vous utilisez ‘comstackr les variables globales’ et / ou ‘comstackr les tableaux globaux’, utilisez mlockall () pour empêcher les erreurs de page lors de leur access.

plus d’informations: HOWTO: créer une application RT

Ils ont également une grande page de publications que vous pourriez vouloir vérifier.

Avez-vous jeté un coup d’oeil à Xenomai ? Il vous permettra d’exécuter des processus “durs en temps réel” au-dessus de Linux, tout en vous permettant d’accéder aux API Linux standard pour tous les besoins non temps réel.

Il existe deux approches fondamentalement différentes pour obtenir des capacités en temps réel avec Linux.

1) Patch le kernel existant avec des choses comme les correctifs rt-preempt. Cela conduira finalement à un kernel entièrement préemptif

2) Approche à double kernel (comme xenomai, RTLinux, RTAI, …)

Il y a beaucoup de choses qui passent d’un RTOS à Linux.

Peut-être que vous n’avez pas vraiment besoin de temps réel?

Je parle de Linux en temps réel dans ma formation: http://www.reliableembeddedsystems.com/embedded-systems_7.html

La réponse est probablement “assez bonne”.

Si vous utilisez un système embarqué, vous avez probablement le contrôle de tous ou de la plupart des logiciels sur la boîte.

Stock Linux 2.6 dispose de plusieurs fonctionnalités adaptées aux tâches à faible latence: principalement:

• Politiques de planification
• Verrouillage de la mémoire

En supposant que vous utilisez une machine à cœur unique, si vous n’avez qu’une seule tâche qui a défini sa politique de planification sur SCHED_FIFO ou SCHED_RR (peu importe si vous avez une seule tâche), ET verrouille toute sa mémoire avec mlockall (), alors il sera planifié dès qu’il sera prêt à fonctionner.

Alors, la seule chose à laquelle vous deviez vous inquiéter était de savoir si une partie non préemptable du kernel prenait plus de temps que votre latence acceptable – ce qui ne devrait pas se produire dans un système embarqué à moins vos pilotes sont douteux.

Je suppose que “essayer et voir” est une bonne réponse, mais c’est probablement plutôt compliqué dans votre cas (et peut impliquer l’écriture de pilotes de périphériques, etc.).

Regardez la doc pour sched_setscheduler pour de bonnes informations.