Entrées-Sorties Et Gestion de La Mémoire Avec Temps Réel - Séance 6

4- Entrées/sorties et gestion de la mémoire avec temps réel
Entrées/sorties et gestion de la mémoire avec temps réel

Cours du Système Embarqué et Temps Réel
Prof. Nabil KANNOUF
UAE – ENSAH
05 Novembre 2021
Plan
1 Variabilité du temps d’exécution
2 Hiérarchies de mémoires
3 Allocation de la mémoire des processus dans Linux
4 Problème d’inversion de priorité
5 Communication entre processus temps réel

4.1- Variabilité du temps d’exécution

Variabilités de l’exécution de programmes temps réel
Variabilité du temps d’exécution : élément central à surveiller

. Temps réel dur : exigence fondamentale de respecter contraintes temporelles sur exé-
cution des tâches
. Temps réel doux : minimiser manquements d’échéances reste très important
. Calculs d’échéance généralement basés sur le pire cas
? Important donc d’éliminer ou de réduire variabilités et latences internes et externes
Variabilités de l’exécution de programmes temps réel
Variabilité du temps d’exécution : élément central à surveiller

. Temps réel dur : exigence fondamentale de respecter contraintes temporelles sur exé-
cution des tâches
. Temps réel doux : minimiser manquements d’échéances reste très important
. Calculs d’échéance généralement basés sur le pire cas
? Important donc d’éliminer ou de réduire variabilités et latences internes et externes
Prévisibilité plutôt que performance
. Préférence pour méthodes à faible variabilité, même si légères pertes de performance
Sources de variabilités
Variabilités internes : rendre programmes temps réels déterministes

. Organiser programme en tâches de durée fixe
. Éviter traitements ayant une grande variabilité (à taille égale), selon les valeurs d’entrée
(considérer pire des cas)
. Faire attention lors d’accès mémoire
. Redoubler d’attention lors d’accès au disque
Sources de variabilités
Variabilités internes : rendre programmes temps réels déterministes

. Organiser programme en tâches de durée fixe
. Éviter traitements ayant une grande variabilité (à taille égale), selon les valeurs d’entrée
(considérer pire des cas)
. Faire attention lors d’accès mémoire
. Redoubler d’attention lors d’accès au disque
Variabilités externes
. Gestion des périphériques
? Appel d’interruption dans le noyau traités de façon prioritaire
. Éviter communication réseau synchrone
? Communication avec routage généralement hors de contrôle
. Délais du système d’exploitation (SE)
? Changement de contexte
? Ordonnancement
Gestion des entrées/sorties
Gestion des entrées/sorties (E/S)

. Pooling
? Attente active sur registres du périphérique

? Consomme une partie des ressources processeur
Gestion des entrées/sorties
Gestion des entrées/sorties (E/S)

. Pooling
? Attente active sur registres du périphérique

? Consomme une partie des ressources processeur
. Interruptions
? Lorsque périphérique prêt à transférer données, signaler processeur par interruption
? Évite de consommer inutilement ressources par attente active
? Requiert cependant de traiter requêtes asynchrones, pouvant survenir à tout moment
? Traité à l’intérieur du noyau, non préemptible par défaut
Gestion des interruptions

Appel de fonction de gestion d’interruption
Tiré de Jim Huang, Making Linux do Hard Real-Time, 2016, CC BY-SA 3.0, http ://www.slideshare.net/jserv/making-linux-do-hard-realtime.
Latence du noyau pour gestion d’interruptions

Typiquement, processus en attente de fin de traitement de l’interruption avant de
reprendre exécution
kernellatency = interruptlatency + handlerduration + schedulerlatency + schedulerduration
Tiré de Jim Huang, Making Linux do Hard Real-Time, 2016, CC BY-SA 3.0,
http ://www.slideshare.net/jserv/making-linux-do-hard-realtime.
Latence du noyau pour gestion d’interruptions

Typiquement, processus en attente de fin de traitement de l’interruption avant de
reprendre exécution
kernellatency = interruptlatency + handlerduration + schedulerlatency + schedulerduration
Toutes proportions gardées, latence introduite peut être importante

Gestion d’interruptions sur multiprocesseur
Solution possible avec multiprocesseur : ne pas exécuter interruptions sur même

coeur que processus temps réel
. Affinité entre IRQ et processeurs donnée dans /proc/irq/XX/smp_affinity
. Lire affinité
$ cat /proc/irq/XX/smp_affinity
f
. Modifier affinité
$ sudo sh -c "echo 1 > /proc/irq/XX/smp_affinity"
. Affinité par défaut : /proc/irq/default_smp_affinity
? Utilisé seulement pour définir affinité de nouvelles interruptions
. Interruptions actives : /proc/interrupts
Appels système
Dans Linux, processus utilisateurs peuvent être préemptés à tout moment ?
. Oui, sauf lors d’appels système
. Appels système effectués en mode privilégié
? Signifie qu’appel système doit se terminer avant que l’on puisse préempter processus
actuel
PREEMPT_RT
Patch PREEMPT_RT de Linux
. Modifications au noyau permettent la préemption des appels système
. Changements pour versions spécifiques du noyau
? Noyau de votre RPi0 inclus la patch
. Vise à minimiser quantité de code du noyau qui n’est pas préemptible
? Force interruptions a être traitées par threads du noyau (kthreads)
? Modifications à deux modèles de synchronisation (RCU et sleeping spinlocks)
? Utilisation du noyau de primitives de synchronisation temps réel (mutex, sleeping spin-
locks, reader-writer locks)
PREEMPT_RT
Patch PREEMPT_RT de Linux
. Modifications au noyau permettent la préemption des appels système
. Changements pour versions spécifiques du noyau
? Noyau de votre RPi0 inclus la patch
. Vise à minimiser quantité de code du noyau qui n’est pas préemptible
? Force interruptions a être traitées par threads du noyau (kthreads)
? Modifications à deux modèles de synchronisation (RCU et sleeping spinlocks)
? Utilisation du noyau de primitives de synchronisation temps réel (mutex, sleeping spin-
locks, reader-writer locks)
Ces modifications rendent Linux plus approprié pour temps réel
. Modifications engendrent aussi quelques inefficacités relativement à la version de base
du noyau
. Même avec PREEMPT_RT, latences de Linux tout de même élevées relativement
d’autres SE temps réel
? Linux n’est pas conçu et pas nécessairement approprié pour temps réel dur
Latence de noyau temps réel
Noyau préemptible : nécessaire pour réduire latence d’exécution
4.2- Hiérarchies de mémoires

Hiérarchies de mémoires
Différents types de mémoires
. DRAM (dynamic RAM) : utilisée pour la mémoire vive
? Doit être rafraîhie régulièrement et après chaque lecture : temps de cycle significatif
? Emphase sur le rapport capacité/coût
. SRAM (static RAM) : utilisée pour les caches
? N’a pas besoin d’être rafraîchie après lecture (temps de cycle faible)
? Emphase sur le vitesse
On veut une mémoire rapide et de grande taille
. Solution : hiérarchies de mémoires
. Tirer avantage des technologies de mémoires (différents compromis coût-performance)
? 90% des accès se font dans 10% de la mémoire

On veut une mémoire rapide et de grande taille
. Solution : hiérarchies de mémoires
. Tirer avantage des technologies de mémoires (différents compromis coût-performance)
? 90% des accès se font dans 10% de la mémoire

Caches permettent de bénéficier du meilleur des deux mondes
. Cependant introduit variabilité non négligeable dans l’exécution, lors de manquements
de caches
Temps d’accès : facteur 10

Capacités de stockage : facteur 1000
Mémoire virtuelle
Organisation de la mémoire au niveau suivant : mémoire virtuelle

. Objets ne sont pas tous dans la mémoire vive d’un processeur, ils peuvent aussi être
sur le disque
. Mémoire virtuelle : diviser la mémoire en pages
Mémoire virtuelle
Organisation de la mémoire au niveau suivant : mémoire virtuelle

. Objets ne sont pas tous dans la mémoire vive d’un processeur, ils peuvent aussi être
sur le disque
. Mémoire virtuelle : diviser la mémoire en pages
Programme qui réfère à une donnée pas en cache, ni dans la mémoire vive : faute
de page
. Charger données d’une page sur disque en mémoire vive
. Conceptuellement similaire è manquement de cache, mais en pratique très différente
dans son exécution
? Manquements de cache : gérés par matériel, quelques centaines de cycles
? Fautes de page : beaucoup plus complexes, gérés en logiciel, par le système d’exploita-
tion
. Faute de page induit délais de dizaine de millions de cycles
? Inadmissible dans systèmes temps réel
Fonctionnement de la mémoire virtuelle
Fonctionnement de la mémoire virtuelle

. Mémoire devient une cache pour le disque dur
. Pages forment blocs de la mémoire virtuelle
. Pages peuvent être déplacées de façon transparente, en mémoire ou sur disque
. Adresses virtuelles utilisées dans les programmes
. Chaque accès implique traduction d’adresse virtuelle en adresse physique
? Traduction en adresses physiques via la table des pages
? Traduction gérée par une combinaison matériel/système d’exploitation
Illustration de la mémoire virtuelle
Tiré de J.L. Hennessy et D.A. Patterson, Computer Architecture : A Quantitative Approach, 6e édition, Elsevier, 2017
Traduction d’adresses
Nombre d’accès pour accéder à une donnée

. Table des pages placée en mémoire, car volumineuse (typiquement 1 Mo à 4 Mo)
. Un accès pour obtenir adresse physique à partir d’adresse virtuelle
. Un accès pour lire la donnée à partir de l’adresse physique
Traduction d’adresses
Nombre d’accès pour accéder à une donnée

. Table des pages placée en mémoire, car volumineuse (typiquement 1 Mo à 4 Mo)
. Un accès pour obtenir adresse physique à partir d’adresse virtuelle
. Un accès pour lire la donnée à partir de l’adresse physique
Réduire les temps d’accès : cache des adresses virtuelles
. Tampon de traduction anticipée (translation look-aside buffer, TLB)
. Indexe les adresses physiques les plus utilisées selon les adresses virtuelles
. Réside dans la puce du microprocesseur
4.3- Allocation de la mémoire des processus dans Linux

Allocation dynamique et copie dans Linux
Allocation dynamique de mémoire : pas de garantis sur latence

. Donc, on doit préallouer mémoire dynamique avant de lancer tâches temps réel

Gestion de la mémoire dans Linux : copy-on-write
. Pages de mémoire partagée : pas recopies
? Copie de la page seulement lors d’une écriture

. Donc, coût très faible lors de copie de données
? Coût plus important (et souvent imprévisible) lors d’écriture sur les données, de l’ordre
d’un manquement de page
? Dans système temps réel, il faut éliminer ces délais
? Fonction mlock (vue plus loin) utile à cette fin

. Donc, coût très faible lors de copie de données
? Coût plus important (et souvent imprévisible) lors d’écriture sur les données, de l’ordre
d’un manquement de page
? Dans système temps réel, il faut éliminer ces délais
? Fonction mlock (vue plus loin) utile à cette fin
. Rend l’exécution globalement rapide, car évite de copies inutiles
? Appel de fonction fork() : pas de coût de recopie de l’espace mémoire du processus
parent
Fonctionnement conceptuel de fork()
Fonctionnement conceptuel de fork() dans Linux
Écriture après fork()
Gérer variabilité associée à la mémoire
Approches pour réduire la variabilité associée à la mémoire

. Minimiser manquements de cache dans le code (facile à dire !)

. Eviter changements de contexte entre tâches et processus
? Avoir quelques tâches plus longues plutôt que plusieurs tâches courtes
? Éviter renouvellement constant de cache et TLB en alternant trop rapidement entre
processus

. Eviter changements de contexte entre tâches et processus
? Avoir quelques tâches plus longues plutôt que plusieurs tâches courtes
? Éviter renouvellement constant de cache et TLB en alternant trop rapidement entre
processus
. Désactiver utilisation du disque dur dans la mémoire virtuelle
? Temps de chargement de page à partir du disque trop élevé pour être tolérable
? De plus, peut survenir à tout moment dans le code
mlock
mlock/munlock : bloquer/débloquer une plage mémoire en mémoire vive

mlock
mlock/munlock : bloquer/débloquer une plage mémoire en mémoire vive

mlockall/munlockall : bloquer/débloquer tout l’espace mémoire du processus actuel
en mémoire vive
. flags : précise fonctionnement du blocage
? MCL_CURRENT bloque espace actuel du processus
? MCL_FUTURE bloque espace future
? MCL_CURRENT | MCL_FUTURE bloque espace actuel et futur
Limitations de mlock
État de blocage n’est pas hérité par les processus enfants (ex. créés par un fork())
Par défaut, quantité de mémoire pouvant être bloqué est limité (typiquement 64
ko)
. Connaître la limite : commande ulimit -l
. Modifier cette limite avec fonction setrlimit
? Requiert des privilèges administrateurs ou modifications aux permissions
? Solution pour cas simples, sans restriction de sécurité : exécuter programme avec sudo
Par défaut, quantité de mémoire pouvant être bloqué est limité (typiquement 64
ko)
. Connaître la limite : commande ulimit -l
. Modifier cette limite avec fonction setrlimit
? Requiert des privilèges administrateurs ou modifications aux permissions
? Solution pour cas simples, sans restriction de sécurité : exécuter programme avec sudo
Appel à mlock/mlockall bloque tant que toutes les pages spécifiées ne sont pas
chargées en mémoire
4.4- Problème d’inversion de priorité

Problème d’inversion de priorité

. Deux tâches de priorités différentes : tâche H de haute priorité et tâche B de basse
priorité

priorité
. Ressource partagée R : ne peut être acquise que par une seule tâche à la fois

priorité
. Tâche H en veille, tâche B s’exécute et acquiert ressource R

priorité
. Tâche H se réveille et préempte tâche B, mais a rapidement besoin de ressource R

priorité
. Tâche H ne peut acquérir la ressource et doit attendre que tâche B libère la ressource
R

priorité
. Tâche H ne peut acquérir la ressource et doit attendre que tâche B libère la ressource
R
. Inversion de priorité : plusieurs tâches de priorité moyenne (priorité plus élevée que B
mais plus faible que H) peuvent alors bloquer l’exécution de B et H indéfiniment
? Tâche B ne s’exécute pas tant qu’une tâche de priorité moyenne peut s’exécuter
? Tâche B donc bloquée et par le fait tâche H aussi
Éviter inversion de priorité
Stratégies pour éviter inversion de priorité

. Désactiver préemption et interruptions durant section critique
? Processus ayant bloqué la ressource ne sera pas interrompu

. Plafonnement de la priorité
? Processus ayant obtenu la ressource aura temporairement la priorité maximale parmi
tous les processus ayant demandé la ressource

. Héritage de la priorité
? Lorsque processus demande une ressource déjà assignée, processus ayant déjà la res-
source hérite temporairement de la priorité plus élevée

. Héritage de la priorité
? Lorsque processus demande une ressource déjà assignée, processus ayant déjà la res-
source hérite temporairement de la priorité plus élevée
. Eviter bloquage
? Synchroniser utilisation des ressources tout en évitant blocages (ex. synchronisation
non-bloquante, read-copy-update)
Threads temps réel dans Linux
Avec mutex POSIX (pthread) sous Linux, propriétés temps réel possibles
. Propriété modifiée via fonction pthread_mutexattr_setprotocol
. Attributs attr du mutex créés préalablement avec fonction pthread_mutexattr_init

. Attributs attr du mutex créés préalablement avec fonction pthread_mutexattr_init

. Paramètre protocol permet de préciser le type de mutex à utiliser
? PTHREAD_PRIO_NONE : mutex usuel (pas temps réel)
? PTHREAD_PRIO_INHERIT : mutex avec héritage de priorité
? PTHREAD_PRIO_PROTECT : section critique exécutée avec plus haute priorité pos-
sible
4.5- Communication entre processus temps réel

Communication entre processus temps réel
Comment communiquer entre processus dans contexte temps réel ?

. Pipes ou socket
? Implique appel fonctions bloquantes (read/write)
? Appel asynchrone évite appels bloquants, mais complique souvent logique du code
? Surcoût associé à copie dans tampons et vérification des valeurs
Communication entre processus temps réel
Comment communiquer entre processus dans contexte temps réel ?

. Pipes ou socket
? Implique appel fonctions bloquantes (read/write)
? Appel asynchrone évite appels bloquants, mais complique souvent logique du code
? Surcoût associé à copie dans tampons et vérification des valeurs
. Partage de plages mémoires entre processus
? Pratiquement instantané
? Minimiser les surcoûts
? Distinction entre threads et processus encore plus floue
mmap : image mémoire

Fonction mmap : créer image en mémoire liée à fichier et/ou partagée
. addr : indication où l’image doit être créée (NULL si on laisse le noyau choisir)
. length : taille de l’image
. prot : protection mémoire désirée (PROT_EXEC, PROT_READ, PROT_WRITE, PROT_NONE)
. flags : propriétés de l’image
? MAP_SHARED : image partagée avec écriture au fichier
? MAP_PRIVATE : image copie locale qui n’affecte pas fichier
? MAP_ANONYMOUS : image anonyme en mémoire, sans lien avec fichier
? MAP_POPULATE : forcer à remplir image avec données du fichier
. fd : descripteur du fichier lié à l’image (-1 si image anonyme)
. offset : déplacement dans fichier correspondant au début de l’image
. Retourne l’adresse effective utilisée pour l’image
Partage d’espace mémoire entre processus
Partage un espace mémoire entre processus parent et enfant
. Processus parent et enfant partage espace mémoire de taille length à l’adresse addr
. On peut définir mutex temps réel (supportant héritage de priorité) dans cet espace
mémoire pour contrôler accès
Image mémoire d’un fichier
Image mémoire d’un fichier
. Échange d’information entre processus via le fichier partagé

. Partager un fichier réel peut engendrer grande quantité de lecture/écriture au disque
? Mauvaise idée dans contexte de temps réel
Mémoire partagée avec shm_open
Partage d’un emplacement en mémoire avec fonction shm_open
. name : nom du fichier, doit commencer par un /, sans en contenir ailleurs dans le nom
(ex. /nomdupartagememoire)
. oflags : masque déterminant l’ouverture du fichier, doit obligatoirement contenir
O_RDONLY ou O_RDWR
? O_RDONLY : partage ouvert en lecture seulement
? O_RDWR : partage ouvert en lecture/écriture
? O_CREAT : créer le partage s’il n’existe pas
? O_EXCL : retourne une erreur si partage existe déjà
? O_TRUNC : si partage existe déjà, redimensionner à une taille nulle
. mode : mode d’ouverture (permissions), typiquement utiliser 0666
Partage mémoire nommé entre processus
Image mémoire par partage mémoire nommé
. Permet échange par mémoire partagée entre deux processus non relatés
. Fonction ftruncate permet de préciser la taille exacte de l’espace mémoire partagé
donné par shm
. Tous processus ouvrant un partage au nom donné pourront partager l’espace mémoire
et ainsi communiquer
Recette pour créer un thread temps réel
Tiré de https ://wiki.linuxfoundation.org/realtime/documentation/howto/applications/application_base



Fin de Séance
Vos Questions ?

Entrées-Sorties Et Gestion de La Mémoire Avec Temps Réel - Séance 6

Transféré par

Informations du document

Titre original

Copyright

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Entrées-Sorties Et Gestion de La Mémoire Avec Temps Réel - Séance 6

Titre original :

Transféré par

Droits d'auteur :

4- Entrées/sorties et gestion de la mémoire avec temps réel

Entrées/sorties et gestion de la mémoire avec temps réel

Prof. Nabil KANNOUF

1 Variabilité du temps d’exécution

3 Allocation de la mémoire des processus dans Linux

4 Problème d’inversion de priorité

5 Communication entre processus temps réel

4.1- Variabilité du temps d’exécution

Variabilités de l’exécution de programmes temps réel

Variabilité du temps d’exécution : élément central à surveiller

Variabilités de l’exécution de programmes temps réel

Variabilité du temps d’exécution : élément central à surveiller

Variabilités internes : rendre programmes temps réels déterministes

Variabilités internes : rendre programmes temps réels déterministes

Gestion des entrées/sorties

Gestion des entrées/sorties (E/S)

? Attente active sur registres du périphérique

Gestion des entrées/sorties

Gestion des entrées/sorties (E/S)

? Attente active sur registres du périphérique

Gestion des interruptions

Latence du noyau pour gestion d’interruptions

kernellatency = interruptlatency + handlerduration + schedulerlatency + schedulerduration

Latence du noyau pour gestion d’interruptions

kernellatency = interruptlatency + handlerduration + schedulerlatency + schedulerduration

Toutes proportions gardées, latence introduite peut être importante

Gestion d’interruptions sur multiprocesseur

Solution possible avec multiprocesseur : ne pas exécuter interruptions sur même

Latence de noyau temps réel

Noyau préemptible : nécessaire pour réduire latence d’exécution

4.2- Hiérarchies de mémoires

? 90% des accès se font dans 10% de la mémoire

? 90% des accès se font dans 10% de la mémoire

Temps d’accès : facteur 10

Organisation de la mémoire au niveau suivant : mémoire virtuelle

Organisation de la mémoire au niveau suivant : mémoire virtuelle

Fonctionnement de la mémoire virtuelle

Fonctionnement de la mémoire virtuelle

Illustration de la mémoire virtuelle

Nombre d’accès pour accéder à une donnée

Nombre d’accès pour accéder à une donnée

4.3- Allocation de la mémoire des processus dans Linux

Allocation dynamique et copie dans Linux

Allocation dynamique de mémoire : pas de garantis sur latence

Allocation dynamique et copie dans Linux

Allocation dynamique de mémoire : pas de garantis sur latence

Allocation dynamique et copie dans Linux

Allocation dynamique de mémoire : pas de garantis sur latence

Allocation dynamique et copie dans Linux

Allocation dynamique de mémoire : pas de garantis sur latence

Fonctionnement conceptuel de fork()

Fonctionnement conceptuel de fork() dans Linux

Écriture après fork()

Gérer variabilité associée à la mémoire

Approches pour réduire la variabilité associée à la mémoire

Gérer variabilité associée à la mémoire

Approches pour réduire la variabilité associée à la mémoire

Gérer variabilité associée à la mémoire

Approches pour réduire la variabilité associée à la mémoire

mlock/munlock : bloquer/débloquer une plage mémoire en mémoire vive

mlock/munlock : bloquer/débloquer une plage mémoire en mémoire vive

4.4- Problème d’inversion de priorité

Problème d’inversion de priorité

Problème d’inversion de priorité

Problème d’inversion de priorité