{"id":2507,"date":"2012-07-02T07:00:22","date_gmt":"2012-07-02T06:00:22","guid":{"rendered":"http:\/\/www.blaess.fr\/christophe\/?p=2507"},"modified":"2012-11-30T13:37:49","modified_gmt":"2012-11-30T12:37:49","slug":"la-pandaboard-au-porteau-de-torture-3-timers-linux-et-linux-rt","status":"publish","type":"post","link":"https:\/\/www.blaess.fr\/christophe\/2012\/07\/02\/la-pandaboard-au-porteau-de-torture-3-timers-linux-et-linux-rt\/","title":{"rendered":"La Pandaboard au porteau de torture – 3 – Timers Linux et Linux-rt"},"content":{"rendered":"

\"La<\/a>J’ai poursuivi les tests entam\u00e9s dans l’article pr\u00e9c\u00e9dent de cette s\u00e9rie<\/a>,\u00a0 en laissant tourner pendant de longues dur\u00e9es un programme qui v\u00e9rifie les fluctuations d’un timer logiciel \u00e0 100 micro-secondes. Voici quelques r\u00e9sultats obtenus sur la Pandaboard avec un noyau Linux 3.4.1 en version \u00ab\u00a0vanilla\u00a0\u00bb pour commencer, puis avec l’application d’un patch Linux-rt par la suite.<\/p>\n

\n\n<\/p>\n

Noyau Linux standard<\/h1>\n

Dans la premi\u00e8re s\u00e9rie d’exp\u00e9riences, mon programme de test se trouvait parfois sur le m\u00eame c\u0153ur de processeur que les traitements d’interruption. Ceci pouvait provoquer des retards tr\u00e8s longs (jusqu’\u00e0 6 millisecondes) dans le d\u00e9clenchement des timers. J’ai alors essay\u00e9 de mieux r\u00e9partir les traitements.<\/p>\n

Pendant plusieurs jours, j’ai fait fonctionner le programme de test sur un c\u0153ur de CPU, apr\u00e8s avoir redirig\u00e9 le traitement des interruptions sur l’autre c\u0153ur. Rappelons que pour transf\u00e9rer le traitement d’une interruption (par exemple 44) sur le second c\u0153ur, il faut \u00e9crire<\/p>\n

[Panda]# echo 2 > \/proc\/irq\/44\/smp_affinity<\/strong>\n[Panda]#<\/pre>\n
La valeur \u00e9crite est un masque repr\u00e9sentant l’ensemble des CPU sur lesquels l’interruption peut \u00eatre trait\u00e9e. Pour rediriger toutes les interruptions vers un c\u0153ur, je fais<\/p>\n
[Panda]# for i in \/proc\/irq\/[0-9]*; do echo 2 > \"$i\/smp_affinity\"; done<\/strong>\n[Panda]#<\/pre>\n
Voici quelques r\u00e9sultats obtenus en pla\u00e7ant successivement la t\u00e2che de mesure sur les c\u0153urs 0 puis 1, et les interruptions sur l’autre c\u0153ur.<\/p>\n
\"Fluctuation<\/a>\"Fluctuation<\/a><\/p>\n
\"Fluctuation<\/a><\/p>\n
Puisque nos r\u00e9sultats sont d\u00e9pendants des traitements des interruptions, il est int\u00e9ressant de r\u00e9aliser les m\u00eames exp\u00e9rimentations avec le noyau Linux-rt qui am\u00e9liorer les performances temps r\u00e9el du noyau standard.<\/p>\n
Noyau Linux modifi\u00e9 par le patch Linux-rt<\/h2>\n
J’ai compil\u00e9 un noyau 3.4.1<\/a> apr\u00e8s avoir appliqu\u00e9 un patch Linux-rt-9<\/a> adapt\u00e9 \u00e0 ce noyau (avec ce fichier de configuration<\/a>).<\/p>\n
La premi\u00e8re ex\u00e9cution s’est d\u00e9roul\u00e9e comme pr\u00e9c\u00e9demment avec les interruptions sur un coeur et la t\u00e2che de mesure sur l’autre coeur. Les r\u00e9sultats sont comparables \u00e0 ceux du noyau standard.<\/p>\n
\"Fluctuations<\/a><\/p>\n
Pour v\u00e9rifier si les r\u00e9sultats sont meilleurs avec Linux-rt ou non, j’ai \u00e0 nouveau laiss\u00e9 le programme s’ex\u00e9cuter sur le m\u00eame c\u0153ur<\/strong> que les traitements d’interruptions.<\/p>\n
L’un des principaux int\u00e9r\u00eats du patch Linux-rt est de proposer des threaded interrupts<\/em>, c’est-\u00e0-dire d’ordonnancer dans des threads du kernel les traitements \u00e0 r\u00e9aliser en r\u00e9ponse aux interruptions, plut\u00f4t que des les ex\u00e9cuter dans des tasklets<\/em> (non ordonnanc\u00e9es, directement en sortie du handler bas-niveau) comme le fait le noyau standard. Nous pouvons profiter de ceci en fixant des priorit\u00e9s temps-r\u00e9els aux traitements qui nous int\u00e9ressent le plus.<\/p>\n
J’ai tout d’abord voulu avoir un \u00e9tat des lieux sur les interrutions \u00ab\u00a0thread\u00e9es\u00a0\u00bb et leur priorit\u00e9. Voyons d’abord la liste des t\u00e2ches apr\u00e8s le boot d’un syst\u00e8me Linux-rt sur la Pandaboard.<\/p>\n
[Panda]# ps<\/strong> \nPID   USER     TIME   COMMAND\n    1 root       0:01 init\n    2 root       0:00 [kthreadd]\n    3 root       0:02 [ksoftirqd\/0]\n    4 root       0:00 [kworker\/0:0]\n    5 root       0:00 [kworker\/u:0]\n    6 root       0:00 [posixcputmr\/0]\n    7 root       0:00 [migration\/0]\n    8 root       0:00 [posixcputmr\/1]\n    9 root       0:00 [migration\/1]\n   10 root       0:00 [kworker\/1:0]\n   11 root       0:01 [ksoftirqd\/1]\n   12 root       0:00 [khelper]\n   13 root       0:00 [kworker\/u:1]\n   20 root       0:00 [irq\/52-gpmc]\n   49 root       0:00 [irq\/41-l3-dbg-i]\n   50 root       0:00 [irq\/42-l3-app-i]\n   96 root       0:00 [irq\/44-DMA]\n  249 root       0:00 [sync_supers]\n  251 root       0:00 [bdi-default]\n  253 root       0:00 [kblockd]\n  266 root       0:00 [omap2_mcspi\/1]\n  268 root       0:00 [omap2_mcspi\/2]\n  270 root       0:00 [omap2_mcspi\/3]\n  272 root       0:00 [omap2_mcspi\/4]\n  282 root       0:00 [khubd]\n  288 root       0:00 [irq\/88-omap_i2c]\n  293 root       0:00 [irq\/39-TWL6030-]\n  294 root       0:00 [twl6030-irq]\n  315 root       0:00 [irq\/89-omap_i2c]\n  317 root       0:00 [irq\/93-omap_i2c]\n  320 root       0:00 [irq\/94-omap_i2c]\n  337 root       0:00 [cfg80211]\n  432 root       0:00 [kswapd0]\n  433 root       0:00 [fsnotify_mark]\n  434 root       0:00 [crypto]\n  448 root       0:00 [irq\/57-OMAP DIS]\n  451 root       0:00 [irq\/85-omapdss_]\n  452 root       0:00 [irq\/116-omapdss]\n  468 root       0:00 [OMAP UART0]\n  470 root       0:00 [OMAP UART1]\n  472 root       0:00 [OMAP UART2]\n  474 root       0:00 [OMAP UART3]\n  551 root       0:00 [irq\/109-ehci_hc]\n  557 root       0:00 [irq\/108-ohci_hc]\n  572 root       0:00 [kpsmoused]\n  575 root       0:00 [kworker\/1:1]\n  579 root       0:00 [irq\/363-rtc0]\n  598 root       0:00 [irq\/115-mmc0]\n  600 root       0:00 [irq\/91-mmc1]\n  616 root       0:00 [irq\/419-hwmod_i]\n  627 root       0:00 [deferwq]\n  633 root       0:00 [mmcqd\/0]\n  638 root       0:00 [kjournald]\n  650 root       0:00 [flush-179:0]\n  662 root       0:00 dropbear -r \/etc\/dbkey.rsa\n  [...]\n[Panda]#<\/pre>\n
Tous les processus dont les noms sont indiqu\u00e9s entre crochets par ps<\/code> sont des threads du kernel. Nous pouvons remarquer ceux qui servent \u00e0 ex\u00e9cuter les traitements en r\u00e9ception d’interruption, dont le nom est pr\u00e9fix\u00e9 par irq\/<\/code> suivi du num\u00e9ro de l’IRQ. Pour conna\u00eetre les priorit\u00e9s temps r\u00e9el de ces threads, j’ai \u00e9crit le petit script suivant<\/p>\n
liste-taches-rt<\/a>:<\/strong> \n#! \/bin\/sh\n\nLISTE_PID=$(ps | awk '{print $1}')\n\nfor PID in $LISTE_PID\ndo \n    chrt -p $PID 2>\/dev\/null | grep 'FIFO|RR' >\/dev\/null 2>&1\n    if [ $? -eq 0 ];  then\n\n        PRIO=$(chrt -p $PID | grep 'priority' | sed 's\/^.*priority: \/\/')\n        CMD=\"$(cat \/proc\/$PID\/comm)\"\n        printf \"%2d %6d %sn\" $PRIO $PID \"$CMD\"\n    fi\ndone | sort -r<\/pre>\n
Voici le r\u00e9sultat sur un noyau Linux-rt fra\u00eechement boot\u00e9<\/p>\n
[Panda]# liste-taches-rt<\/strong> \n99      9 migration\/1\n99      8 posixcputmr\/1\n99      7 migration\/0\n99      6 posixcputmr\/0\n50    616 irq\/419-hwmod_i\n50    600 irq\/91-mmc1\n50    598 irq\/115-mmc0\n50    579 irq\/363-rtc0\n50    557 irq\/108-ohci_hc\n50    551 irq\/109-ehci_hc\n50    452 irq\/116-omapdss\n50    451 irq\/85-omapdss_\n50    448 irq\/57-OMAP DIS\n50    320 irq\/94-omap_i2c\n50    317 irq\/93-omap_i2c\n50    315 irq\/89-omap_i2c\n50    293 irq\/39-TWL6030-\n50    288 irq\/88-omap_i2c\n50     96 irq\/44-DMA\n50     50 irq\/42-l3-app-i\n50     49 irq\/41-l3-dbg-i\n50     20 irq\/52-gpmc\n 1     11 ksoftirqd\/1\n 1      3 ksoftirqd\/0\n[Panda]#<\/pre>\n
Nous remarquons que les t\u00e2ches migration<\/code> et posixcputmr<\/code> (un exemplaire sur chaque c\u0153ur) sont les plus prioritaires du syst\u00e8me. Ensuite se trouvent les traitements pour les interruptions mat\u00e9rielles. Enfin les t\u00e2ches ksoftirq<\/code> sont les plus faibles en priorit\u00e9s temps r\u00e9el (elle sont toutefois plus prioritaires que toutes les t\u00e2ches temps partag\u00e9).<\/p>\n
J’ai choisi de lancer la t\u00e2che de mesure sur le m\u00eame CPU que les interruptions, mais \u00e0 une priorit\u00e9 (70)\u00a0 plus \u00e9lev\u00e9e que les interruptions trait\u00e9es par les drivers de p\u00e9riph\u00e9riques et inf\u00e9rieure \u00e0 celles des handlers les plus prioritaires.<\/p>\n
\"Fluctuation<\/a><\/p>\n
Afin de soumettre la carte \u00e0 une charge tr\u00e8s \u00e9lev\u00e9e en interruptions, elle \u00e9tait la cible de deux \u00ab\u00a0ping<\/em>\u00a0\u00bb en mode flood<\/em> suppl\u00e9mentaires par rapport aux exp\u00e9riences pr\u00e9c\u00e9dentes (donc trois ping<\/em> en tout provenant de trois h\u00f4tes sur le m\u00eame r\u00e9seau).<\/p>\n
Nous voyons que les performances moyennes sont \u00e9quivalentes \u00e0 celles obtenues avec un noyau Linux standard dans les m\u00eames circonstances (dans l’article pr\u00e9c\u00e9dent<\/a>). Les r\u00e9sultats pour les pires fluctuations sont assez sensiblement meilleurs qu’avec Linux vanilla.<\/p>\n
J’ai prolong\u00e9 ce test durant une\u00a0 journ\u00e9e suppl\u00e9mentaire, ce qui confirme ces r\u00e9sultats :<\/p>\n
\"Fluctuation<\/a><\/p>\n
Conclusion<\/h1>\n
En utilisant sur la Pandboard le noyau Linux standard ou celui \u00ab\u00a0patch\u00e9\u00a0\u00bb Linux-rt, nous avons observ\u00e9 que les timers logiciels offraient une tr\u00e8s bonne stabilit\u00e9 en moyenne<\/span> : sur chaque intervalle de cinq secondes, la p\u00e9riode mesur\u00e9e moyenne est entre 99 et 100 microsecondes pour une p\u00e9riode demand\u00e9e de 100 microsecondes.<\/p>\n
Lorsque le syst\u00e8me n’est pas particuli\u00e8rement charg\u00e9 ou lorsque la t\u00e2che de mesure s’ex\u00e9cute sur un coeur de processeur peu sollicit\u00e9 par les interruptions, les retards de traitement restent inf\u00e9rieurs \u00e0 la milliseconde.<\/p>\n
En revance, si le syst\u00e8me est tr\u00e8s charg\u00e9 – notamment en interruption – les pires retards peuvent atteindre plusieurs millisecondes (2 \u00e0 3 avec Linux-rt, plus de 6 avec Linux standard). Ceci est repr\u00e9sentatif d’un syst\u00e8me temps r\u00e9el souple (soft realtime<\/em>), et ces performances peuvent s’av\u00e9rer insuffisantes dans certaines applications. Dans le prochain article nous allons reprendre les m\u00eames mesures sur un noyau comportant l’extension Xenomai et v\u00e9rifier si le comportement temps r\u00e9el est vraiment am\u00e9lior\u00e9.<\/p>\n
Pour en savoir plus…<\/h1>\n