O temps suspends ton vol...

Je viens de voir à l'occasion de la sortie du kernel Linux 2.6.25 l'existence de l'outil latencytop. De quoi au moins outiller mes propos, pour les latences que l'outil saura mesurer.

Après parcours de la liste des innovations de la 2.6.25, il semble que l'effervescence se soit calmée pour la partie scheduler. Tant mieux, il y a tant à dire pour la 2.6.24 !

Les latences possibles que j'imagine au niveau kernel (les freins à une latence faible) ?

- tout d'abord le matériel. Il est illusoire de demander à un ARM2 à 8MHz d'obtenir une latence identique à un Core2 duo dont la fréquence interne est facilement 250 fois supérieure ! De même les accès RAM et les débits RAM ont profité d'une amélioration spectaculaire ces 10 dernières années et les systèmes auxquels on demande les meilleures perfs RT ne sont pas les machines dernier cri...

- ensuite le codage interne du kernel. Blocage sous Mutex, Ordonnaceur trop long, interruptions désactivées trop longtemps sont les principales causes d'accroissement de latence. Un handler d'IT mal écrit peut décider de la latence complète du système. Ce n'est pas propre à Linux, un vendeur d'OS temps réel l'a appris à ses dépends sur son propre driver disque dur !

- Enfin l'utilisation du système. une machine qui croule régulièrement sous la charge, dimensionnée pour accepter juste la charge, ne sera peut-être pas en mesure de tenir systématiquement uen latence faible. On ne peut exiger d'une machine prévue pour bosser 10 secondes à 110% de ses capacités de prétendre avoir un comportement temps réel pendant cette surcharge sans risquer de voir certaines piles déborder (au mieux), certaines latences diverger (au pire).

Donc on commencera à parler de temps réel sous les conditions suivantes :

- Les erreurs de codage manifestes sont exclues,

- L'erreur de sous-dimensionnement pour de longs intervalles est écartée,

- On demande au matériel des latences qu'il a une chance de tenir.