Table des matières
Nous allons voir dans ce chapitre l'évaluation des systèmes qui font l'objet de la synthèse du chapitre 6.
Lorsqu'on conçoit un système embarqué, c'est à dire un système fonctionnant sur une petite carte électronique, on est souvent confronté à de fortes contraintes sur :
Celle-ci est souvent très limitée pour des raisons de coût mais surtout de place. Sur de tels systèmes, il n'y a généralement que quelques méga-octets, et tout gaspillage peut produire un effondrement des performances. De plus, étant donné qu'il n'y a pas de disque dur, la sauvegarde des pages mémoires[23] est impossible. Cela signifie qu'en cas d'espace mémoire insuffisant, le noyau Linux supprimera aléatoirement des processus pour libérer de la place.
On ne parle pas de vitesse de calcul, mais de temps de latence faible, il ne faut pas se tromper de sujet ! Le vrai problème est donc le délai entre le moment où l'action est commandée et le moment où elle est effectuée. Qui n'a jamais perdu son sang-froid contre son téléphone portable qui met plus de trois secondes à afficher un simple menu... Plus sérieusement, dans les applications industrielles, des temps de latence faible permettent parfois de se passer d'un système temps réel.
Il existe plusieurs solutions pour réduire la mémoire utilisée :
Celui-ci prend généralement entre 500 Ko et 1.5 Mo. Sachant qu'il n'existe pas de projet visant à diminuer sa taille, c'est au concepteur du système de bien choisir les fonctionnalités et les pilotes à incorporer.
Pour cela, on peut bien évidemment compiler avec l'option -Os de GCC, puis élaguer les binaires avec l'utilitaire strip. Mais c'est surtout le concepteur du système qui doit faire attention aux ressources, et doit alors utiliser des logiciels spécialement conçus pour le domaine de l'embarqué. Cela permet alors de réduire considérablement la taille du RAMDisk, ce qui économise de la mémoire statique[24], ainsi que la taille des processus, d'où une économie de mémoire dynamique[25].
Enfin, il faut savoir qu'il existe encore d'autres méthodes pour diminuer la mémoire utilisée, comme par exemple le système d'"eXecute In Place" (XIP) qui permet d'exécuter le noyau (et les applications) directement à partir d'une ROM, sans recopie en RAM.
Le fait de diminuer la taille du RAMDisk permet d'augmenter considérablement la réactivité du système lors du (re-)démarrage. En effet, on a alors :
Cela fait gagner le temps de décompression. Ce point est contradictoire avec le premier. Il faut donc utiliser cette technique uniquement lorsque le temps de chargement du RAMDisk compressé et de sa décompression est supérieur au temps de chargement du RAMDisk décompressé. La figure suivante illustre le problème :
Lorsqu'on a moins de mémoire utilisée par le RAMDisk et/ou par les processus, la réactivité du système peut augmenter. En effet, cela permet d'avoir :
Ainsi, le concepteur de l'application peut calculer la taille maximale qu'aura besoin son programme durant l'exécution et ainsi allouer statiquement un gros bloque de mémoire. Il faut savoir que les appels aux fonctions malloc/realloc/free peuvent diminuer considérablement les performances d'une application, il est donc préférable de ne pas en avoir besoin.
Le noyau utilise toujours le maximum de mémoire disponible, notamment pour gérer ce que l'on appelle les caches (pas ceux du processeur). Comme leurs noms l'indiquent, ces bloques mémoire permettent de garder une copie des applications et des données en mémoire vive. On voit parfaitement leur utilité lorsqu'on lance Mozilla ou OpenOffice sur sa station de travail : la première exécution est beaucoup moins rapide que les autres, celles-ci utilisant les caches.
Enfin, le temps de latence peut être diminué en utilisant un noyau modifié, avec les correctifs preempt-kernel et/ou low-latency par exemple (déjà intégrés au noyau 2.6), mais cela fait l'objet d'une autre étude.
