Voici les r\u00e9ponses aux exercices de mon livre \u00ab\u00a0Solutions temps r\u00e9el sous Linux\u00a0\u00bb. Certaines questions n’admettent pas une r\u00e9ponse unique et vous pouvez avoir une approche tout \u00e0 fait diff\u00e9rente. N’h\u00e9sitez pas \u00e0 me faire part de vos r\u00e9sultats, vos id\u00e9es, vos remarques concernant ces exercices ; ceci me permettra d’enrichir cette page de solutions.<\/p>\n
L’archive compl\u00e8te des solutions des exercices se trouve ici : corrections-strsl.tar.bz2<\/strong><\/a><\/p>\n <\/p>\n Le contenu du fichier Le fichier \u00ab\u00a0 Le fichier \u00ab\u00a0 Une solution est impl\u00e9ment\u00e9e dans le fichier \u00ab\u00a0 Les tentatives d’envoi de signal sur le fils n’ont aucun effet, il est d\u00e9j\u00e0 mort !<\/p>\n Pour s’en d\u00e9barasser, il faut terminer le processus p\u00e8re. Lorsqu’un processus meurt, ses fils (zombies ou non) sont adopt\u00e9s par le processus num\u00e9ro 1 (init<\/em>) qui vient lire le statut de terminaison et les zombies disparaissent alors.<\/p>\n En ex\u00e9cutant \u00ab\u00a0 Ceci d\u00e9pend largement du syst\u00e8me et du noyau install\u00e9.<\/p>\n En pressant une touche du clavier ou en d\u00e9pla\u00e7ant la souris vous verrez une interruption se produire. Parfois il s’agit d’une interruption provoqu\u00e9e par un contr\u00f4leur USB auquel le clavier ou la souris sont branch\u00e9s.<\/p>\n Supposons que votre souris soit sur l’interruption 18, et qu’elle soit trait\u00e9e majoritairement sur le CPU 0, alors que vous disposez de quatre c\u0153urs. Vous pouvez forcer le traitement sur le c\u0153ur 2 en utilisant :<\/p>\n La valeur a \u00e9crire est 2 puissance le num\u00e9ro du c\u0153ur voulu (num\u00e9rot\u00e9 \u00e0 partir de z\u00e9ro). Il faut avoir les droits root<\/em> pour effectuer cette modification.<\/p>\n Pour effectuer une division par z\u00e9ro sans que le compilateur ne s’en rende compte et nous l’interdise \u00e0 la compilation, il suffit d’utiliser le nombre d’arguments sur la ligne de commande. C’est ce qui est impl\u00e9ment\u00e9 dans le fichier \u00ab\u00a0 Pour d\u00e9clencher l’exception \u00ab\u00a0Illegal instruction<\/em>\u00ab\u00a0, il faut ex\u00e9cuter du code invalide pour le processeur employ\u00e9. C’est difficile avec les architectures actuelles car les pages de code sont verrouill\u00e9es en lecture seule (donc impossible de modifier des fonctions existantes) et les pages de donn\u00e9es ne sont pas ex\u00e9cutables (donc impossible d’y d\u00e9router l’ex\u00e9cution).<\/p>\n La solution consiste \u00e0 g\u00e9n\u00e9rer un code assembleur invalide et \u00e0 l’ins\u00e9rer manuellement dans un programme C, comme c’est fait dans le fichier \u00ab\u00a0 Comme on peut s’y attendre, le nombre de boucles par dizaine de secondes reste a peu pr\u00e8s constant, et se r\u00e9partit \u00e9quitablement entre les processus.<\/p>\n En utilisant la commande La r\u00e9daction du script shell n’est pas \u00e9vidente car il faut lancer les vingt processus en parall\u00e8le et trier leurs r\u00e9sultats. On en trouvera un exemple dans le fichier Pour tester les r\u00e9sultats de l’exercice pr\u00e9c\u00e9dent sur plusieurs versions du noyau Linux, il faut r\u00e9aliser une longue s\u00e9rie de compilations (comme indiqu\u00e9 dans l’annexe I). J’ai compil\u00e9 un noyau Vanilla<\/em> 2.6.39.9 sur une distribution Ubuntu 11.10. La premi\u00e8re version sans l’option Les r\u00e9sultats sont les suivants, en commen\u00e7ant sur un syst\u00e8me faiblement charg\u00e9.<\/p>\n et<\/p>\n Peu de diff\u00e9rences notables dans le comportement. Voyons \u00e0 pr\u00e9sent sur un syst\u00e8me avec une charge en processus assez \u00e9lev\u00e9e.<\/p>\n et<\/p>\n Dans le second cas, l’ensemble des processus se sont partag\u00e9 le temps CPU attribu\u00e9 \u00e0 leur terminal, sans perturber excessivement les autres t\u00e2ches du syst\u00e8me. On pourra trouver plus d’informations dans cet article<\/a>.<\/p>\n Les informations sur le m\u00e9canisme des Cr\u00e9ons un groupe (arbitrairement nomm\u00e9) que nous limiterons au CPU 3 de cette machine, en lui attribuan le noeud m\u00e9moire z\u00e9ro.<\/p>\n Pla\u00e7ons notre shell (dont le PID est donn\u00e9 par la variable V\u00e9rifions l’affinit\u00e9 de notre shell.<\/p>\n L’affinit\u00e9 est Le d\u00e9placement n’est pas autoris\u00e9. Les affectations par le m\u00e9canisme <\/p>\n La modification de la priorit\u00e9 temps partag\u00e9 n’a pas d’influence sur le nombre d’appels syst\u00e8me Les op\u00e9rations ont \u00e9t\u00e9 d\u00e9crites pages 72 et 73, les statistiques peuvent pr\u00e9senter de grosses variations d’une ex\u00e9cution \u00e0 l’autre en fonction de la charge du syst\u00e8me.<\/p>\n Vous devriez obtenir des histogrammes proches de ceux pr\u00e9sent\u00e9s pages 77 et 79. Il est n\u00e9cessaire d’installer le programme Gnuplot pour disposer d’une repr\u00e9sentation graphique. En principe on arrive a obtenir un timer de qualit\u00e9 correcte avec une p\u00e9riode de quelques millisecondes, et un syst\u00e8me peu charg\u00e9.<\/p>\n Plus les perturbations externes seront fortes (tant en interruptions qu’en charge syst\u00e8me), plus le timer fluctuera. Dans des situations extr\u00e8mes, les ecarts pourront m\u00eame d\u00e9passer la seconde.<\/p>\n Les dur\u00e9es maximales des pr\u00e9emptions d\u00e9pendent tr\u00e8s fortement du mat\u00e9riel, de sa charge en interruption et de sa charge en processus. Sur un syst\u00e8me peu charg\u00e9, il ne doit pas y avoir de pr\u00e9emption sup\u00e9rieure \u00e0 une milliseconde. On peut s’en assurer ainsi.<\/p>\n Pour affiner l’exp\u00e9rience, il peut s’av\u00e9rer n\u00e9cessaire d’allonger la dur\u00e9e initiale de \u00ab\u00a0 Le script \u00ab\u00a0 Il faut disposer des droit root<\/em> (ou employer On peut v\u00e9rifier l’ordonnancement configur\u00e9 avec Le shell ne pr\u00e9sente pas de modification de son comportement, mais tous les processus qu’il lance d\u00e9marreront en temps r\u00e9el.<\/p>\n Le script Au lancement du programme le syst\u00e8me semble fig\u00e9, mais quelques t\u00e2ches temps partag\u00e9 arrivent \u00e0 s’ex\u00e9cuter quand m\u00eame, \u00e0 cause du param\u00e8tre Il n’est pas simple de trouver toutes les t\u00e2ches \u00e0 passer en temps r\u00e9el pour conserver le contr\u00f4le de l’interface graphique malgr\u00e9 la boucle active. J’ai d\u00e9j\u00e0 remarqu\u00e9 que les fen\u00eatres des terminaux en mode texte semblent recevoir des rafales de retours-chariot si elles n’ont pas d’acc\u00e8s au CPU pendant un temps prolong\u00e9. Je suppose que cela est li\u00e9 \u00e0 un d\u00e9lai de timeout<\/em> qui expire et correspond \u00e0 l’\u00e9mission d’un caract\u00e8re break<\/em> vers le terminal.<\/p>\n L’ex\u00e9cution de Le programme Sur la plupart des syst\u00e8mes, la fluctuation d’un timer (l’\u00e9cart type des p\u00e9riodes mesur\u00e9es) reste inf\u00e9rieure \u00e0 5% de la p\u00e9riode si celle-ci est de l’ordre d’une cinquantaine de microsecondes au minimum.<\/p>\n La mesure du temps de commutation entre threads synchronis\u00e9s par un mutex peut se faire en employant le programme \u00ab\u00a0 Les temps de commutation entre processus peuvent \u00eatre l\u00e9g\u00e8rement plus longs, ceci \u00e9tant d\u00fb \u00e0 la m\u00e9moire virtuelle, et \u00e0 la n\u00e9cessit\u00e9 de modifier la configuration de la MMU.<\/p>\n Vous trouverez des exemples de mesure de l’efficacit\u00e9 des outils de synchronisation et de communication entre processus dans les articles suivants.<\/p>\n Pour synchroniser le d\u00e9marrage de plusieurs processus distincts, il est possible de verrouiller un s\u00e9maphore Posix avant leur lancement (ou de l’initialiser avec un compteur \u00e0 z\u00e9ro). Chaque processus demande le s\u00e9maphore (et reste donc bloqu\u00e9 initialment) puis le rel\u00e2che imm\u00e9diatement.<\/p>\n Le processus principal, apr\u00e8s avoir cr\u00e9\u00e9 tous les processus fils va les laisser d\u00e9marrer en rel\u00e2chant le s\u00e9mpahore. Vous en trouverez une impl\u00e9mentation dans le fichier L’impl\u00e9mentation propos\u00e9 dans \u00ab\u00a0 Il n’existe pas d’h\u00e9ritage de priorit\u00e9 sur les s\u00e9maphores, car \u00e0 la diff\u00e9rence des mutex, ceux-ci n’ont pas de propri\u00e9taire. Un s\u00e9maphore est essentiellement un compteur, qui peut prendre une valeur positive ou nulle. Lorsque le s\u00e9maphore est \u00e0 z\u00e9ro, n’importe quel processus peut l’incr\u00e9menter. Il n’y a pas de notion de processus qui \u00ab\u00a0tient\u00a0\u00bb le s\u00e9maphore, comme un thread tient un mutex.<\/p>\n Sur un syst\u00e8me o\u00f9 les mutex n’offrent pas d’h\u00e9ritage de priorit\u00e9, une solution classique pour \u00e9viter les inversions de priorit\u00e9, est de rendre un thread non-pr\u00e9emptible d\u00e8s qu’il tient un objet de synchronisation. Sur certains syst\u00e8mes d’exploitation, on r\u00e9alise ceci en bloquant les interruptions. Pour travailler de mani\u00e8re portable, je proposerai plut\u00f4t de monter la priorit\u00e9 du thread tenant un mutex \u00e0 la valeur la plus \u00e9lev\u00e9e possible.<\/p>\n Dans le fichier \u00ab\u00a0 Le fichier \u00ab\u00a0 Pour qu’il y ait un partage \u00e9quitable de l’acc\u00e8s au s\u00e9maphore, et que les processus l’obtiennent les uns apr\u00e8s les autres, il est n\u00e9cessaire d’introduire un appel \u00e0 Pour compiler un noyau modifi\u00e9 avec le patch Linux-rt, je vous conseille de vous reporter aux pages 169 et 170, ainsi qu’aux articles suivants.<\/p>\n Les r\u00e9sultats obtenus avec \u00ab\u00a0 Sur un noyau vanilla<\/em>, une boucle active de priorit\u00e9 \u00e9lev\u00e9e est pr\u00e9empt\u00e9e par le noyau d\u00e8s qu’une op\u00e9ration est \u00e0 r\u00e9aliser en r\u00e9ponse \u00e0 une interruption. Et les t\u00e2ches r\u00e9seau d’un noyau standard sont consid\u00e9r\u00e9es comme suffisamment prioritaires pour \u00eatre trait\u00e9es directement \u00e0 la r\u00e9ception de l’interruption. Ainsi, m\u00eame si une t\u00e2che de priorit\u00e9 Fifo<\/em> 99 est active, on l’interrompra pour r\u00e9pondre \u00e0 un ping<\/em>. Avec un noyau modifi\u00e9 Linux-rt, les traitements en r\u00e9ponse aux interruptions sont effectu\u00e9s dans des threads<\/em> du kernel, ordonnanc\u00e9s avec une priorit\u00e9 temps-r\u00e9el 50. Si une t\u00e2che utilisateur est active avec une priorit\u00e9 sup\u00e9rieure, les threads<\/em> du noyau (et donc la r\u00e9ponse au ping<\/em>), seront retard\u00e9s jusqu’\u00e0 la fin de la t\u00e2che de haute priorit\u00e9.<\/p>\n Si vous montez le thread<\/em> kernel correspondant \u00e0 l’interface r\u00e9seau \u00e0 une priorit\u00e9 sup\u00e9rieure \u00e0 celle de la boucle, le syst\u00e8me r\u00e9pond \u00e0 nouveau au ping<\/em>.<\/p>\n On trouvera les \u00e9l\u00e9ments de r\u00e9ponse dans cet article<\/a>.<\/p>\n Vous trouverez la derni\u00e8re version de Xenomai ici : http:\/\/www.xenomai.org\/<\/a><\/p>\n T\u00e9l\u00e9chargez l’archive, d\u00e9compressez-la, et v\u00e9rifiez le patch le plus r\u00e9cent pour votre architecture. T\u00e9l\u00e9chargez le noyau Linux (sur http:\/\/www.kernel.org<\/a>) correspondant. Vous trouverez les d\u00e9tails pages 193 et 194.<\/p>\n Pour la compilation du noyau avec Xenomai, je vous propose un premier article<\/a> (installation sur une distribution Ubuntu) et un second<\/a> sur carte \u00e0 processeur Arm.<\/p>\n Apr\u00e8s compilation des biblioth\u00e8ques (voir pages 197 et 198), le programme Les r\u00e9sultats de cette exp\u00e9rience sont tr\u00e8s variables d’une architecture \u00e0 l’autre. Sur les PC on remarque souvent des fluctuations plus importantes sur des machines de bureau que sur des postes industriels. A titre d’exemple, sur un PC industriel avec une charge tr\u00e8s \u00e9lev\u00e9 en interruptions et en processus, j’ai observ\u00e9 en une journ\u00e9e une fluctuation maximale de 36 microsecondes sur un timer programm\u00e9 \u00e0 10kHz.<\/p>\n Le programme \u00ab\u00a0 Le programme \u00ab\u00a0 Nous voyons des fluctuations de l’ordre de quelques dizaines de microsecondes<\/p>\n Apparemment, les fluctuations avec \n
Chapitre 1<\/h1>\n
Exercice 1-1<\/h2>\n
\/proc\/cpuinfo<\/code> et la mani\u00e8re de l’analyser sont d\u00e9crits page 8.<\/p>\nExercice 1-2<\/h2>\n
solution-01-02.c<\/code>\u00a0\u00bb contient une impl\u00e9mentation possible.<\/p>\n$ gcc -o solution-01-02 solution-01-02.c -pthread -lrt<\/strong>\n$ .\/solution-01-02 <\/strong>\n (Contr\u00f4le-C<\/em>)<\/strong>\n$<\/pre>\n
Exercice 1-3<\/h2>\n
solution-01-03.c<\/code>\u00a0\u00bb permet de r\u00e9aliser l’op\u00e9ration demand\u00e9e. On suit la progression sur un autre terminal, et l’on voit bien les passages en \u00e9tats R<\/code> (Running<\/em>), S<\/code> (Sleeping<\/em>), T<\/code> (Traced<\/em>).<\/p>\n$ gcc -o solution-01-03 solution-01-03.c<\/strong>\n$ .\/solution-01-03<\/strong>\n[25579] Boucle active...\n $ ps aux | grep 25579 | grep -v grep<\/strong>\n cpb 25579 99.8 0.0 1820 248 pts\/4 R+ 10:33 0:05 .\/solution-01-03\n[25579] Sommeil...\n $ ps aux | grep 25579 | grep -v grep<\/strong>\n cpb 25579 97.5 0.0 1820 248 pts\/4 S+ 10:33 0:14 .\/solution-01-03\n[25579] Boucle active...\n $ kill -STOP 25579<\/strong>\n[1]+ Stopp\u00e9 .\/solution-01-03\n$\n $ ps aux | grep 25579 | grep -v grep<\/strong>\n cpb 25579 65.1 0.0 1820 248 pts\/4 T 10:33 0:18 .\/solution-01-03\n $ kill -CONT 25579\n $ ps aux | grep 25579 | grep -v grep<\/strong>\n cpb 25579 57.1 0.0 1820 248 pts\/4 R 10:33 0:21 .\/solution-01-03\n [25579] Sommeil...\n[25579] Boucle active...\n $ kill -TERM 25579<\/strong>\n $\n$<\/pre>\n
Exercice 1-4<\/h2>\n
solution-01-04.c<\/code>\u00ab\u00a0. Lorsqu’on l’ex\u00e9cute on voit que le processus fils devient Zombie<\/em> au bout de dix secondes. Ceci signifie qu’il est termin\u00e9 mais que son p\u00e8re n’a pas lu son statut de terminaison.<\/p>\n$ gcc -o solution-01-04 solution-01-04.c <\/strong>\n$ .\/solution-01-04 <\/strong>\n[27004] Je suis le processus pere...\n[27005] Je suis le processus fils...\n $ ps aux | grep 27005 | grep -v grep<\/strong>\n cpb 27005 0.0 0.0 1820 56 pts\/4 S+ 10:47 0:00 .\/solution-01-04\n[27005] Je vais me terminer...\n $ ps aux | grep 27005 | grep -v grep<\/strong>\n cpb 27005 0.0 0.0 0 0 pts\/4 Z+ 10:47 0:00 [solution-01-04]\n $ kill -TERM 27005<\/strong>\n $ ps aux | grep 27005 | grep -v grep<\/strong>\n cpb 27005 0.0 0.0 0 0 pts\/4 Z+ 10:47 0:00 [solution-01-04]\n $ kill -INT 27005<\/strong>\n $ ps aux | grep 27005 | grep -v grep<\/strong>\n cpb 27005 0.0 0.0 0 0 pts\/4 Z+ 10:47 0:00 [solution-01-04]\n $ kill -9 27005<\/strong>\n $ ps aux | grep 27005 | grep -v grep<\/strong>\n cpb 27005 0.0 0.0 0 0 pts\/4 Z+ 10:47 0:00 [solution-01-04]\n $<\/pre>\n
$ kill 27004<\/strong>\nComplete\n$\n $ ps aux | grep 27005 | grep -v grep<\/strong>\n $<\/pre>\n
Chapitre 2<\/h1>\n
Exercice 2-1<\/h2>\n
watch -n 0.1 cat \/proc\/interrupts<\/code>\u00a0\u00bb (ou 0,1<\/strong> \u00e9ventuellement) vous devriez voir une interruption se d\u00e9clencher p\u00e9riodiquement. Peut-\u00eatre une interruption locale, interne au processeur. Sur la plupart des distributions actuelles, la fr\u00e9quence du timer est \u00e0 250Hz ou 300Hz. Aussi, en observant le chiffre des milliers d’interruptions, vous devriez le voir \u00e9voluer toutes les 3 \u00e0 4 secondes.<\/p>\nExercice 2-2<\/h2>\n
Exercice 2-3<\/h2>\n
# echo 4 > \/proc\/irq\/18\/smp_affinity<\/pre>\n
Exercice 2-4<\/h2>\n
solution-02-04.c<\/code>\u00a0\u00bb qui d\u00e9clenche bien l’exception attendue.<\/p>\n$ .\/solution-02-04 abcdef <\/strong>\nJe vais calculer i=1\/1\nLe resultat est 1\n$ .\/solution-02-04 abcdef ghijkl<\/strong>\nJe vais calculer i=1\/2\nLe resultat est 0\n$ .\/solution-02-04 <\/strong>\nJe vais calculer i=1\/0\nException en point flottant\n$<\/pre>\n
Exercice 2-5<\/h2>\n
solution-02-05.c<\/code>\u00a0\u00bb (les instructions sont invalides pour un processeur x86, il faudra peut-\u00eatre changer les valeurs si on le teste sur une autre architecture).<\/p>\n$ gcc -o solution-02-05 solution-02-05.c <\/strong>\n$ .\/solution-02-05 <\/strong>\nJ'execute la fonction avec le code invalide...\nInstruction non permise\n$<\/pre>\n
Chapitre 3<\/h1>\n
Exercice 3-1<\/h2>\n
$ .\/exemple-taux-cpu <\/strong>\n[3036] nb_boucles : 79183231\n$ .\/exemple-taux-cpu & .\/exemple-taux-cpu <\/strong>\n[3039] nb_boucles : 40693996\n[3040] nb_boucles : 40694974\n$ .\/exemple-taux-cpu & .\/exemple-taux-cpu & .\/exemple-taux-cpu <\/strong>\n[3133] nb_boucles : 26061303\n[3131] nb_boucles : 25634096\n[3132] nb_boucles : 25702652\n$<\/pre>\n
Exercice 3-2<\/h2>\n
nice<\/code> on favorise un processus par rapport \u00e0 l’autre. Plus la valeur transmise \u00e0 nice<\/code> est \u00e9lev\u00e9e, plus le processus est p\u00e9nalis\u00e9.<\/p>\n$ .\/exemple-taux-cpu & nice -n +3 .\/exemple-taux-cpu <\/strong>\n[3611] nb_boucles : 25088529\n[3610] nb_boucles : 49568574\n$ .\/exemple-taux-cpu & nice -n +5 .\/exemple-taux-cpu <\/strong>\n[3701] nb_boucles : 56678953\n[3702] nb_boucles : 18291412\n$ .\/exemple-taux-cpu & nice -n +10 .\/exemple-taux-cpu <\/strong>\n[3705] nb_boucles : 74797470\n[3706] nb_boucles : 7845659\n$ .\/exemple-taux-cpu & nice -n +20 .\/exemple-taux-cpu <\/strong>\n[3709] nb_boucles : 79928673\n[3710] nb_boucles : 1187910\n$<\/pre>\n
Exercice 3-3<\/h2>\n
solution-03-03.sh<\/code>. Notez que les valeurs croissantes de nice<\/code> correspondent aux valeurs croissantes de PID.<\/p>\n$ .\/solution-03-03.sh <\/strong>\n[3841] nb_boucles : 16599509\n[3842] nb_boucles : 13338231\n[3843] nb_boucles : 10650787\n[3844] nb_boucles : 8574728\n[3845] nb_boucles : 6903253\n[3846] nb_boucles : 5472881\n[3847] nb_boucles : 4428908\n[3848] nb_boucles : 3508128\n[3849] nb_boucles : 2801397\n[3850] nb_boucles : 1995259\n[3851] nb_boucles : 1601489\n[3852] nb_boucles : 1265770\n[3853] nb_boucles : 1044762\n[3854] nb_boucles : 910331\n[3855] nb_boucles : 749787\n[3856] nb_boucles : 584887\n[3857] nb_boucles : 486954\n[3858] nb_boucles : 389343\n[3859] nb_boucles : 285891\n[3860] nb_boucles : 251992\n$<\/pre>\n
Exercice 3-4<\/h2>\n
autogroup<\/code>, et l’autre avec cette option. Les fichiers de configuration des noyaux se trouvent dans l’archive des solutions.<\/p>\nOption autogroup NON activ\u00e9e<\/strong>:\n[2065] nb_boucles : 15809768\n[2066] nb_boucles : 12317797\n[2067] nb_boucles : 10108224\n[2068] nb_boucles : 7879477\n[2069] nb_boucles : 6340445\n[2070] nb_boucles : 5023591\n[2071] nb_boucles : 4191715\n[2072] nb_boucles : 3326890\n[2073] nb_boucles : 2662925\n[2074] nb_boucles : 2135578\n[2075] nb_boucles : 1701423\n[2076] nb_boucles : 1327210\n[2077] nb_boucles : 1075745\n[2078] nb_boucles : 865417\n[2079] nb_boucles : 698098\n[2080] nb_boucles : 547356\n[2081] nb_boucles : 449937\n[2082] nb_boucles : 353484\n[2083] nb_boucles : 287868\n[2084] nb_boucles : 224124<\/pre>\n
Option autogroup activ\u00e9e<\/strong>\n[4124] nb_boucles : 16547401\n[4125] nb_boucles : 13360087\n[4126] nb_boucles : 10621702\n[4127] nb_boucles : 8524357\n[4128] nb_boucles : 6842971\n[4129] nb_boucles : 5452880\n[4130] nb_boucles : 4413384\n[4131] nb_boucles : 3516360\n[4132] nb_boucles : 2820007\n[4133] nb_boucles : 2236505\n[4134] nb_boucles : 1784830\n[4135] nb_boucles : 1423908\n[4136] nb_boucles : 1163712\n[4137] nb_boucles : 928116\n[4138] nb_boucles : 761456\n[4139] nb_boucles : 589009\n[4140] nb_boucles : 495110\n[4141] nb_boucles : 397024\n[4142] nb_boucles : 296815\n[4143] nb_boucles : 263285<\/pre>\n
Option autogroup NON activ\u00e9e<\/strong>:\n[2294] nb_boucles : 11454211\n[2295] nb_boucles : 9183630\n[2296] nb_boucles : 7472511\n[2297] nb_boucles : 6001470\n[2298] nb_boucles : 4813134\n[2299] nb_boucles : 3762535\n[2300] nb_boucles : 3110984\n[2301] nb_boucles : 2394422\n[2302] nb_boucles : 1934842\n[2303] nb_boucles : 1581542\n[2304] nb_boucles : 1235447\n[2305] nb_boucles : 988488\n[2306] nb_boucles : 819291\n[2307] nb_boucles : 644526\n[2308] nb_boucles : 514887\n[2309] nb_boucles : 419180\n[2310] nb_boucles : 326733\n[2311] nb_boucles : 255844\n[2312] nb_boucles : 222833\n[2313] nb_boucles : 188144<\/pre>\n
Option autogroup activ\u00e9e<\/strong>\n[4362] nb_boucles : 4972521\n[4363] nb_boucles : 4015143\n[4364] nb_boucles : 3176701\n[4365] nb_boucles : 2553396\n[4366] nb_boucles : 2069002\n[4367] nb_boucles : 1648680\n[4368] nb_boucles : 1324571\n[4369] nb_boucles : 1069048\n[4370] nb_boucles : 838920\n[4371] nb_boucles : 679788\n[4372] nb_boucles : 551903\n[4373] nb_boucles : 451465\n[4374] nb_boucles : 354519\n[4375] nb_boucles : 290077\n[4376] nb_boucles : 224147\n[4377] nb_boucles : 190850\n[4378] nb_boucles : 158436\n[4379] nb_boucles : 126133\n[4380] nb_boucles : 93978\n[4381] nb_boucles : 88006<\/pre>\n
Exercice 3-5<\/h2>\n
cgroups<\/code> se trouvent dans le r\u00e9pertoire Documentation\/cgroups<\/code> \u00e0 l’int\u00e9rieur des sources du noyau Linux. Montons le syst\u00e8me de fichiers correspondant si ce n’est pas fait par la distribution<\/p>\n# mount | grep cgroup<\/strong>\n# mkdir -p \/dev\/cgroup<\/strong>\n# mount none \/dev\/cgroup\/ -t cgroup -o cpuset<\/strong>\n# ls \/dev\/cgroup\/<\/strong>\ncgroup.clone_children cpuset.cpu_exclusive cpuset.mem_hardwall cpuset.memory_pressure_enabled cpuset.mems notify_on_release\ncgroup.event_control cpuset.cpus cpuset.memory_migrate cpuset.memory_spread_page cpuset.sched_load_balance release_agent\ncgroup.procs cpuset.mem_exclusive cpuset.memory_pressure cpuset.memory_spread_slab cpuset.sched_relax_domain_level tasks\n#<\/pre>\n
# mkdir \/dev\/cgroup\/CPU-3<\/strong>\n# ls \/dev\/cgroup\/CPU-3\/<\/strong>\ncgroup.clone_children cgroup.procs cpuset.cpus cpuset.mem_hardwall cpuset.memory_pressure cpuset.memory_spread_slab cpuset.sched_load_balance notify_on_release\ncgroup.event_control cpuset.cpu_exclusive cpuset.mem_exclusive cpuset.memory_migrate cpuset.memory_spread_page cpuset.mems cpuset.sched_relax_domain_level tasks\n# echo 3 > \/dev\/cgroup\/CPU-3\/cpuset.cpus<\/strong>\n# echo 0 > \/dev\/cgroup\/CPU-3\/cpuset.mems <\/strong>\n#<\/pre>\n
$$<\/code>) dans ce groupe.<\/p>\n# echo $$ > \/dev\/cgroup\/CPU-3\/tasks<\/strong>\n#<\/pre>\n
# taskset -p $$<\/strong>\npid 29562's current affinity mask: 8\n#<\/pre>\n
8<\/code> (2^3<\/code>), le shell ne peut donc fonctionner que sur le CPU 3. Essayons de le replacer sur le CPU 0.<\/p>\n# taskset -pc 0 $$<\/strong>\npid 29562's current affinity list: 3\ntaskset: failed to set pid 29562's affinity: Argument invalide\n#<\/pre>\n
cgroups<\/code> est plus contraignant que la simple modification de l’affinit\u00e9. Les processus ne peuvent plus sortir des CPU qui leur ont \u00e9t\u00e9 attribu\u00e9s.<\/p>\nChapitre 4<\/h1>\n
Exercice 4-1<\/h2>\n
gettimeofday()<\/code> que notre processus r\u00e9ussit \u00e0 effectuer par micro-seconde.<\/p>\nExercice 4-2<\/h2>\n
Exercice 4-3<\/h2>\n
Exercice 4-4<\/h2>\n
Exercice 4-5<\/h2>\n
$ .\/exemple-gettimeofday-02 1000\n$<\/pre>\n
exemple-gettimeofday-02.c<\/code>\u00a0\u00bb (ligne 51, la dur\u00e9e initiale est de cinq secondes).<\/p>\nChapitre 5<\/h1>\n
Exercice 5-1<\/h2>\n
cherche-taches-rt.sh<\/code>\u00a0\u00bb permet d’afficher les param\u00e8tres des processus ordonnanc\u00e9s Round Robin<\/em> ou Fifo<\/em>. En voici un exemple d’utilisation.<\/p>\n$ .\/cherche-taches-rt.sh<\/strong>\npid 11's current scheduling policy: SCHED_FIFO\npid 11's current scheduling priority: 99\npid 14's current scheduling policy: SCHED_FIFO\npid 14's current scheduling priority: 99\npid 21514's current scheduling policy: SCHED_RR\npid 21514's current scheduling priority: 1\npid 6's current scheduling policy: SCHED_FIFO\npid 6's current scheduling priority: 99\npid 7's current scheduling policy: SCHED_FIFO\npid 7's current scheduling priority: 99\n$<\/pre>\n
Exercice 5-2<\/h2>\n
sudo<\/code>) pour passer l’ordonnancement d’une t\u00e2che en temps r\u00e9el. Pour modifier l’ordonnancement du shell, on peut employer la variable $$<\/code> qui est toujours initialis\u00e9e avec son propre PID.<\/p>\n$ sudo chrt -pf 10 $$\n[sudo] password for cpb:<\/pre>\n
chrt<\/code> \u00e9galement.<\/p>\n$ chrt -p $$\npid 11868's current scheduling policy: SCHED_FIFO\npid 11868's current scheduling priority: 10\n$<\/pre>\n
Exercice 5-3<\/h2>\n
passer-taches-rt.sh<\/code> passe en ordonnancement Fifo priorit\u00e9 10 tous les processus initialement en temps partag\u00e9. Le syst\u00e8me fonctionne tout \u00e0 fait normalement. Il peut y avoir n\u00e9anmoins des p\u00e9riodes de gel temporaire de l’activit\u00e9 lorsqu’on ex\u00e9cute des processus qui consomme beaucoup de CPU (calcul, compilation, etc.).<\/p>\nExercice 5-4<\/h2>\n
\/proc\/sys\/kernel\/sched_rt_runtime_us<\/code> comme indiqu\u00e9 page 99. En \u00e9crivant -1<\/code> dans ce pseudo-fichier, on peut geler temporairement tout le syst\u00e8me avec des boucles actives.<\/p>\nExercice 5-5<\/h2>\n
Chapitre 6<\/h1>\n
Exercice 6-1<\/h2>\n
exemple-timer-create-02.c<\/code> sous un ordonnancement temps r\u00e9el permet d’obtenir un r\u00e9sultat plus fiable (mais pas plus rapide bien s\u00fbr) qu’en temps partag\u00e9. Les fluctuations devraient se compter en dizaines de micro-secondes<\/p>\nExercice 6-2<\/h2>\n
exemple-perturbateur.c<\/code> cr\u00e9ant essentiellement de la charge CPU en temps partag\u00e9, il n’a que tr\u00e8s peu d’influence sur le timer. Si on l’ordonnance en temps-r\u00e9el, il pourra perturber tr\u00e8s violement le timer aussit\u00f4t que leurs priorit\u00e9s seront identiques.<\/p>\nExercice 6-3<\/h2>\n
Exercice 6-4<\/h2>\n
exemple-commutations-threads.c<\/code>\u00a0\u00bb de la mani\u00e8re d\u00e9crite pages 117 \u00e0 120. Pour r\u00e9aliser la m\u00eame mesure sur des processus sycnhronis\u00e9s par un s\u00e9maphore, employez le programme \u00ab\u00a0exemple-commutation-processus.c<\/code>\u00a0\u00bb tel qu’indiqu\u00e9 page 121.<\/p>\nExercice 6-5<\/h2>\n
\n
Chapitre 7<\/h1>\n
Exercice 7-1<\/h2>\n
solution-07-01.c<\/code>.<\/p>\nExercice 7-2<\/h2>\n
solution-07-02.c<\/code>\u00a0\u00bb nous d\u00e9montre qu’une situation d’inversion de priorit\u00e9 peut se produire sur un s\u00e9maphore (P2 s’ex\u00e9cute avant P3).<\/p>\n# .\/solution-07-02 <\/strong>\nP1 demarre\nP1 demande le sempahore\nP1 tient le semaphore\nP1 cree P3\n P3 demarre\n P3 demande le semaphore\nP1 cree P2\n P2 demarre\n P2 se termine\nP1 lache le semaphore\n P3 tient le sempahore\n P3 lache le semaphore\n P3 se termine\nP1 se termine\n#<\/pre>\n
Exercice 7-3<\/h2>\n
solution-07-03.c<\/code>\u00a0\u00bb j’ai encapsul\u00e9 les appels pthread_mutex_lock()<\/code> et pthread_mutex_unlock()<\/code> dans des fonctions qui modifient la priorit\u00e9 du thread appelant. Notez que le r\u00e9sultat d’ex\u00e9cution \u00e9vite bien l’inversion de priorit\u00e9, mais n’est pas tout \u00e0 fait identique \u00e0 celui obtenu page 147 avec le Priority Inheritance Protocol<\/em>.<\/p>\n# .\/solution-07-03<\/strong>\nT1 demarre\nT1 demande le mutex\nT1 tient le mutex\nT1 cree T3\nT1 cree T2\nT1 lache le mutex\n T3 demarre\n T3 demande le mutex\n T3 tient le mutex\n T3 lache le mutex\n T3 se termine\n T2 demarre\n T2 se termine\nT1 se termine\n#<\/pre>\n
Exercice 7-4<\/h2>\n
solution-07-04.c<\/code>\u00a0\u00bb permet de s’assurer qu’un s\u00e9maphore est bien obtenu par le processus le plus prioritaire qui le demande. Dans le cas d’un ordonnancement en Round Robin<\/em>, les processus obtiennent le s\u00e9maphore dans l’ordre d’arriv\u00e9e (l’ordre de demande).<\/p>\nExercice 7-5<\/h2>\n
sched_yield()<\/code>, comme nous en avons parl\u00e9 page 159.<\/p>\n# chrt -r 10 .\/solution-07-05 & chrt -r 10 .\/solution-07-05 & chrt -r 10 .\/solution-07-05 &<\/strong>\n[1] 15403\n[2] 15404\n[3] 15405\n#\n[15405] demande le semaphore\n [15405] tient le semaphore\n[15404] demande le semaphore\n[15403] demande le semaphore\n [15405] lache le semaphore\n [15404] tient le semaphore\n[15405] demande le semaphore\n [15404] lache le semaphore\n [15403] tient le semaphore\n[15404] demande le semaphore\n [15403] lache le semaphore\n [15405] tient le semaphore\n[15403] demande le semaphore\n [15405] lache le semaphore\n [15404] tient le semaphore\n[15405] demande le semaphore\n [15404] lache le semaphore\n [15403] tient le semaphore\n[15404] demande le semaphore\n [15403] lache le semaphore\n [15405] tient le semaphore\n[15403] demande le semaphore\n [15405] lache le semaphore\n [15404] tient le semaphore\n[15405] demande le semaphore\n [15404] lache le semaphore\n [15403] tient le semaphore\n[15404] demande le semaphore\n [15403] lache le semaphore\n [15405] tient le semaphore\n[15403] demande le semaphore\n# killall solution-07-05<\/strong>\n [15405] lache le semaphore\n [15404] tient le semaphore\n [15404] lache le semaphore\n [15403] tient le semaphore\n [15403] lache le semaphore\n[1] Compl\u00e9t\u00e9 chrt -r 10 .\/solution-07-05\n[2]- Compl\u00e9t\u00e9 chrt -r 10 .\/solution-07-05\n[3]+ Compl\u00e9t\u00e9 chrt -r 10 .\/solution-07-05\n#<\/pre>\n
Chapitre 8<\/h1>\n
Exercice 8-1<\/h2>\n
\n
Exercice 8-2<\/h2>\n
exemple-timer-create-02.c<\/code>\u00a0\u00bb sur un noyau modifi\u00e9 avec le patch Linux-rt devraient \u00eatre plus fiables qu’avec le noyau vanilla<\/em> si le processus est ex\u00e9cut\u00e9 avec une priorit\u00e9 assez \u00e9lev\u00e9e. Les diff\u00e9rences appara\u00eetront lorsque la charge en interruption augmente (avec un ping flood<\/em> par exemple).<\/p>\nExercice 8-3<\/h2>\n
Exercice 8-4<\/h2>\n
Exercice 8-5<\/h2>\n
Chapitre 9<\/h1>\n
Exercice 9-1<\/h2>\n
Exercice 9-2<\/h2>\n
Exercice 9-3<\/h2>\n
latency<\/code> vous permettre d’obtenir des r\u00e9sultats similaires \u00e0 ceux pr\u00e9sent\u00e9s\u00a0 page 201.<\/p>\nExercice 9-4<\/h2>\n
Chapitre 10<\/h1>\n
Exercice 10-1<\/h2>\n
solution-10-01.c<\/code>\u00a0\u00bb propose une impl\u00e9mentation de boucle active de 10 secondes sur tous les CPU. Pendant l’ex\u00e9cution, tout le syst\u00e8me est gel\u00e9. Depuis un autre poste, le ping<\/em> se comporte ainsi:<\/p>\n$ ping 192.168.3.1<\/strong>\n64 bytes from 192.168.3.1: icmp_req=41 ttl=64 time=0.660 ms\n64 bytes from 192.168.3.1: icmp_req=42 ttl=64 time=0.838 ms\n (ex\u00e9cution du programme)\n64 bytes from 192.168.3.1: icmp_req=43 ttl=64 time=9936 ms\n64 bytes from 192.168.3.1: icmp_req=44 ttl=64 time=8937 ms\n64 bytes from 192.168.3.1: icmp_req=45 ttl=64 time=7937 ms\n64 bytes from 192.168.3.1: icmp_req=46 ttl=64 time=6937 ms\n64 bytes from 192.168.3.1: icmp_req=47 ttl=64 time=5937 ms\n64 bytes from 192.168.3.1: icmp_req=48 ttl=64 time=4937 ms\n64 bytes from 192.168.3.1: icmp_req=49 ttl=64 time=3938 ms\n64 bytes from 192.168.3.1: icmp_req=50 ttl=64 time=2938 ms\n64 bytes from 192.168.3.1: icmp_req=51 ttl=64 time=1938 ms\n64 bytes from 192.168.3.1: icmp_req=52 ttl=64 time=938 ms\n64 bytes from 192.168.3.1: icmp_req=53 ttl=64 time=0.840 ms\n64 bytes from 192.168.3.1: icmp_req=54 ttl=64 time=0.843 ms<\/pre>\n
Exercice 10-2<\/h2>\n
solution-10-02.c<\/code>\u00a0\u00bb permet de mesurer la dur\u00e9e d’une boucle programm\u00e9e avec rt_timer_spin()<\/code>. La dur\u00e9e th\u00e9orique est 1 seconde, les valeurs affich\u00e9es sont des nanosecondes.<\/p>\n# .\/solution-10-02 <\/strong>\nduree : 1000018442\nduree : 1000029363\nduree : 1000011173\nduree : 1000016787\nduree : 1000011203<\/pre>\n
Exercice 10-3<\/h2>\n
rt_task_sleep()<\/code> sont un peu plus importantes qu’avec rt_timer_spin()<\/code> comme en t\u00e9moigne le programme \u00ab\u00a0solution-10-03.c<\/code>\u00a0\u00bb dont les r\u00e9sultats sont les suivants. Obtenez-vous la m\u00eame conclusion ?<\/p>\n#