Retour d’expérience

Nous avons travaillé sur plusieurs plates-formes embarquées différentes, trois au total. Nous avons tout d’abord travaillé sur la carte UDOO [18], puis une carte Nvidia Jetson TK1 [8], et enfin sur la carte Juno ARM64 présentée dans ce cha-pitre. Chaque carte intègre du matériel spécifique, lié aux besoins du système. Par exemple, les cartes réseaux utilisées ne sont pas toujours "standard", de même pour

6 – SWAT : système de workflow pour l’analyse de traces 0 2 4 6 8 10 12

all-events libc only perf-trace time

(a)compress-gzip 0 2 4 6 8 10 12

all-events libc only perf-trace time

(b)ffmpeg 0 5 10 15 20 25

all-events libc only perf-trace time (c)network-loopback 0 500 1000 1500 2000 2500

all-events libc only perf-trace time

(d)pybench 0 2000 4000 6000 8000 10000 12000 14000 16000

all-events libc only perf-trace time

(e) ramspeed 0 1 2 3 4 5 6 7 8 9 10

all-events libc only perf-trace time

(f)unpack-linux

Figure6.19 – Variation du score des benchmarks selon les configurations (x86)

les contrôleurs vidéos. Contrairement aux système x86 classiques, les noyaux Li-nux utilisés sont compilés spécifiquement pour chaque plate-forme, afin d’intégrer les pilotes nécessaires au fonctionnement des différents composants. Ces différentes cartes sont donc fournies avec un système Linux spécifique. Les outils que nous vou-lions utiliser n’étaient pas toujours compatibles avec ces spécificités. Par exemple, l’utilisation des compteurs de performance requière une configuration particulière 102

Résultats – 6.3 du noyau Linux, qui doit entièrement être compilé à nouveau si celle-ci n’est pas activée. Nous avons donc utilisé un noyau générique "multi-plates-formes" : le noyau

armmpdisponible dans les dépôts Debian. Ce noyau utilise un fichierDevice Tree dé-crivant la plate-forme afin d’utiliser les bon pilotes selon la plate-forme sur laquelle il s’exécute. L’utilisation de ce noyau à tout de même nécessité des modifications sur les cartes, notamment la mise à jour et la configuration du bootloader, ou encore la désactivation manuelle de certain pilotes qui rendaient une des plate-forme instable. La taille des traces générées fut un réel défi tant en terme de stockage, que de transfert et de traitement. En effet nous avons présenté ici des résultats sur un en-semble de traces, représentant environ un téra-octet de données, mais plusieurs itéra-tions on dû être faites tout au long du développement de notre processus d’analyse. Par exemple, pour certains benchmarks très intensifs en production d’événements, une partie de ces événements étaient perdue au moment du traçage à cause d’une mauvaise configuration de LTTng et de la taille desbuffers utilisés. Différentes traces ont dû être générées aussi lors des changements des versions de noyau afin d’obtenir des traces comparables sur les différentes architectures. C’est donc au final beaucoup de données qui ont été générées, dont certaines sur des plates-formes distantes (la carte Juno étant sur une grille de calcul) incluant un temps de transfert de ces don-nées non négligeable. Les premières analyses ont été faites sur des implémentations en Python présentés dans le chapitre précédent, moins performant que notre outil, le temps d’analyse était lui aussi conséquent et se comptait en jours. Malgré les per-formances de notre infrastructure, les analyses nécessitent tout de même plusieurs heures de calcul.

Au vu du nombre de plates-formes, de benchmarks, de configurations et du nombre d’exécutions, nous avons automatisé la phase de traçage, qui lui aussi nous a posé problème. En effet, malgré une attention particulière sur le fait d’utiliser des systèmes similaires sur les différentes plates-formes, leur configuration peut diffé-rer. Le benchmark network-loopbackpar exemple utilise en interne le programme

netcat. Or plusieurs versions de ce programme sont disponibles et selon les ma-chines, la version "classique" denetcat peut être installée ou alors la version BSD. Le benchmark network-loopbackutilise un paramètre du programme disponible que dans la version BSD, pour les plates-formes ou l’autre version est installée, il en résulte donc une exécution erronée, qui de plus n’est pas notifiée par PTS.

Nous pouvons enfin citer un dernier problème que nous avons rencontré, concer-nant les compteurs de performance mal configurés. En effet, l’accès aux compteurs de performance est spécifique à chaque processeur, c’est au noyau de faire le lien entre pour pouvoir y accéder. Sur la plate-forme ARM, nous avions constamment un nombre égal pour les compteursL1-dcache-loadsetL1-dcache-stores, devant compter les accès en lecture et en écriture au cache L1. Après avoir investigué les compteurs matériels nous nous sommes rendus compte que cette valeur était en fait la valeur du compteur L1-dcache-access qui représente déjà la somme des accès en lecture et en écriture. Nous avions donc le double d’événements du nombre d’ins-truction mémoire dans nos analyse lorsque l’on faisait la somme des deux compteurs.

6 – SWAT : système de workflow pour l’analyse de traces

6.4 Conclusion

Nous avons proposé une implémentation en C++ de notre modèle d’analyse par workflow. Cette implémentation propose les interfaces de programmation nécessaires afin de facilement pouvoir l’adapter à tout types d’analyse. Nous avons conçu des modules dédiés à l’analyse de traces. Nous avons ensuite construit en utilisant cette infrastructure un workflow complexe, composé de ces modules d’analyse, afin de calculer des profils d’utilisation du système. Ce profil renseigne des informations telles que l’occupation CPU, le parallélisme, l’utilisation détaillée des ressources noyau ainsi que de la mémoire.

Notre infrastructure d’analyse nous a permis de traiter environ 50 milliards d’évé-nements contenus dans nos traces, ce qui représente près d’un téra-octet de données. Cela à été possible grâce aux mécanismes de transfert par flux des données mis en place dans l’implémentation du workflow. Au final nous avons pu analyser un sous-ensemble debenchmarks issus de la suite PTS. Nous avons pu comprendre leur fonc-tionnement en détail sans aucune information préalable. Le fait que l’infrastructure puisse supporter le traitement de grandes quantités de données nous a enfin permis de faire des analyses sur de nombreuses exécutions des benchmarks, permettant de mettre en évidence une stabilité quant au comportement de ceux-ci.

L’outil que nous proposons actuellement se présente sous la forme du mécanisme d’exécution de workflow. L’interface de construction du workflow se fait de manière programmatique. A terme, il pourrait être intégré dans VisTrails afin de remplacer le mécanisme d’exécution de workflow actuel. Ce remplacement permettrait de tirer parti des avantages de VisTrails tels que la méthode graphique de constructions de workflow, la gestion d’historique, de cache, ou encore la gestion de provenance des données. Ainsi, VisTrails permettrait l’exécution de workflows basés sur les méthodes de streaming, tout en proposant une exécution performante.

Troisième partie