7.1 Objectifs de la thèse
L’objectif de cette thèse est de proposer des méthodes et outils génériques pour la validation des systèmes embarqués via des traces d’exécution.
Avec la présence croissante des systèmes embarqués dans notre quotidien, et leur complexification au fil du temps, la validation de ces systèmes est devenue une étape capitale. L’utilisation des traces d’exécution pour la validation a prouvé son effica-cité face aux validations par méthodes formelles, trop coûteuses à mettre en place pour des systèmes aussi complexes. Cependant, les outils actuellement utilisés pour analyser les traces d’exécution ne sont pas suffisants. Souvent trop spécifiques, ou res-treints en termes de fonctionnalités, les développeurs sont confrontés aux difficultés de l’utilisation de plusieurs outils, non prévus pour un fonctionnement collaboratif. Dès lors, la mise en place de mécanismes de conversion de formats de traces est nécessaire, ainsi qu’un traitement des données produites par ces outils.
Dans cette thèse, nous proposons un environnement d’analyse dont le but est d’unifier et d’automatiser les traitements et analyses des traces d’exécution. En pro-posant un format de trace générique et enrichi en sémantique, nous permettons des analyses poussées prenant en compte des informations spécifiques et permettons un premier niveau d’analyse automatique. Notre environnement d’analyse étant basé sur un mécanisme de workflow, nous permettons une construction d’analyses sim-plifiée, ainsi qu’une exécution automatisée et collaborative, utilisant plusieurs com-posants d’analyse. Enfin, nous proposons une méthodologie d’analyse générique de systèmes Linux, fondée sur notre modèle de données et d’analyse par workflow, permettant la compréhension du fonctionnement d’applications sans aucune infor-mationa priori, et s’appliquant au cas des systèmes embarqués.
7 – Conclusion et perspectives
7.2 Proposition, réalisation et validation
L’étude des outils d’analyse de traces nous a permis de mettre en évidence les lacunes de ces outils, notamment concernant les aspects de collaboration ainsi que la personnalisation des traitements appliqués aux données. L’étude des outils d’analyse basés sur les workflows, nous a permis de mettre en évidence les critères nécessaires pour la mise en place d’un environnement d’analyse de traces à base de workflows. Ces critères regroupent notamment les aspects de gestion de grandes quantités de données, ou encore la modularité relative à la construction du workflow.
Nous avons proposé un modèle de représentation des traces d’exécution enrichi en sémantique. Ce modèle de trace permet de structurer les informations relatives aux événements, et ainsi d’exprimer des notions plus complexes. Ces notions sont basées sur ce qui se fait déjà dans les outils, en interne, sur les représentations inter-médiaires de la trace et de manière non standardisée. Le modèle que nous proposons permet de représenter des événements ponctuels, des événements représentant un état du système borné dans le temps, des événements de causalité entre deux en-tités, ainsi que des événements représentant l’évolution d’une valeur au cours du temps. Nous avons conçu un outil d’analyse exploitant les notions que nous pro-posons dans le modèle. Cet outil, que nous avons développé et intégré au sein de l’outil Framesoc du projet SoC-TRACE, permet de retrouver des corrélations entre événements. Nous avons montré, sur des traces issues de cas d’usages proposés par la société STMicroelectronics, partenaire du projet SoC-TRACE, que l’utilisation de notre modèle de traces est utile lors de l’analyse des systèmes. Les traces, que nous avons enrichies de manière semi-automatique, puis analysées via l’outil de corréla-tion nous ont permis de retrouver la cause des anomalies présentes dans la trace. Ces résultats ont été validés avec les équipes de développement de STMicroelectronics.
Suite à l’étude des outils d’analyse de traces d’exécution, et de outils d’analyse de données par workflow, nous avons proposé un modèle d’analyse de traces à base de workflows. Utilisant des composants à connecter les uns aux autres, ce modèle permet de définir des analyses complexes. Les connexions, représentant des flux de données, utilisent des mécanismes de streaming permettant de traiter de grandes quantités de données en continu. Nous avons réalisé une première implémentation de ce modèle en collaboration avec l’équipe ViDA de l’Université de New-York. Cette équipe est en charge du développement de VisTrails, un outil de workflow pour l’analyse spécialisé dans la simulation, l’exploration, et la visualisation de données. Notre implémentation a permis le traitement de grosses traces d’exécution, chose impossible dans la version officielle actuelle de l’outil VisTrails. Nous avons validé notre proposition et cette première implémentation sur un exemple synthétique, montrant la simplicité de construction d’analyse par workflow, ainsi que l’efficacité de traitement des données par mécanisme de streaming. Nous sommes actuellement en discussion avec l’équipe de développement de VisTrails sur l’évolution de son moteur d’exécution afin d’intégrer les mécanismes de streaming proposés.
Nous avons proposé, enfin, un modèle d’analyse générique dédié à l’observation des programmes sur un système Linux. En utilisant les interfaces du noyau Linux, ainsi que de la bibliothèque standard C, nous avons proposé une méthode de traçage 108
Perspectives – 7.3 d’applications. La méthode n’a pas besoin de connaissances préalables sur les appli-cations et n’impose pas de modifiappli-cations sur celles-ci. Les traces obtenues permettent une compréhension des aspects d’utilisation des ressources de calcul, de la mémoire, et de l’utilisation des fonctions du noyau. Nous avons réalisé le prototypeStreamed Workflow Analysis Tool (SWAT) fournissant une seconde implémentation de notre modèle de workflow en tant qu’outil indépendant. Forts de l’expérience avec l’outil VisTrails, ce prototype synthétise notre compréhension de ce que devrait être un workflow pour l’analyse de traces et bénéficie de nombreuses optimisations d’implé-mentation. Nous avons utilisé SWAT pour mettre en place notre workflow d’analyse de performances et l’avons instancié dans le cadre du benchmarkPhoronix Test Suite
(PTS). Nous avons pu collecter et analyser des traces de manière automatique sur les différents benchmarks. Cette étude a confirmé la nécessité de compréhension du fonctionnement de benchmarks, car ils adoptent des usages très différents des res-sources systèmes. La généricité de cette analyse a permis d’observer des programmes utilisant des technologies différentes, mais aussi l’observation d’un même programme sur des architectures différentes. Nous avons réussi à traiter près de 1TB de traces et avons expérimenté sur quatre différentes plates-formes comprenant des machines de travail standard et des dispositifs embarqués.
7.3 Perspectives
Plusieurs améliorations sont directement envisageables à la suite nos travaux. Concernant le modèle de données, dans notre travail, la structuration de la trace est faite une seule fois en utilisant une interprétation possible des données brutes. Or, ces données brutes peuvent être structurées de différentes manières reflétant différentes vues de l’exécution. Par exemple, nous avons utilisé les informations d’ordonnancement pour représenter l’exécution des processus. Il serait possible de structurer la trace en prenant en compte les utilisateurs ou des aspects énergétiques. Il serait donc intéressant de voir comment faire co-exister plusieurs structurations de la même trace.
Concernant notre outil SWAT, les performances obtenues sont prometteuses, et une intégration dans l’outil VisTrails est prévue. Ceci nécessite néanmoins une analyse sur l’adaptation des des différentes fonctionnalités de VisTrails, comme par exemple la gestion d’un cache de calcul, au transfert de données par streaming. Nous avons proposé un ensemble de modules d’analyse que nous avons exploité dans nos différentes expérimentations. L’enrichissement de cet ensemble avec des modules diverses de calcul statistique, de fouille de données ou de visualisation est un développement naturel de ce travail.
Concernant notre modèle d’analyse générique, celle-ci pourrait exploiter d’autres métriques de performances. Par exemple, l’utilisation plus large des fonctions de la librairie standard C, les interruptions matérielles ou encore le détail des appels sys-tèmes. De plus, LTTng permet d’envoyer une sur le réseau, permettant le traitement sur une autre machine par exemple. Nous avons montré que le temps d’analyse était en moyenne deux fois le temps d’exécution, cependant la taille des traces (plusieurs centaines de giga-octets) et la quantité d’événements (plusieurs dizaines de millions)
7 – Conclusion et perspectives
explique cela. Il serait possible de créer un workflow d’analyse plus simple, sur des traces moins conséquentes, utilisant une trace générée en continu, afin de proposer un outil d’analyse en temps réel.
Enfin, une analyse exhaustive de tous les benchmarks de la suite PTS serait possible afin de proposer les profils d’analyse aux utilisateurs. Ceux-ci pourrait alors choisir quels benchmarks et quelles configurations utiliser en comprenant pleinement le fonctionnement de ces benchmarks.
Nous sommes convaincus de l’utilité des systèmes de workflow pour les outils d’analyse de données et nous avons exploré une première voie d’application dans le domaine d’analyse des traces d’exécution de systèmes embarqués. Néanmoins, une généralisation de l’approche nécessiterait une investigation sur plusieurs volets. Du point de vue du domaine d’application, nous pensons que les méthodes d’analyse doivent explicitement permettre la capture de la sémantique métier. Dans notre cas, pour que les workflows d’analyse soient largement diffusés et utilisés dans le contexte des systèmes embarqués, un travail important devrait être effectué sur les types de nouvelles analyses de traces à mettre en place. Or, comment représenter la sémantique des système embarqués tout en incluant des aspects d’architecture, ainsi que des aspects applicatifs ? Du point de vue de l’analyse de traces, nous ne sommes qu’aux phases exploratoires d’observation de métriques d’exécution et d’analyse approfondie. En effet, dans une majorité d’outils les métriques reflètent directement l’exécution bas niveau d’un système et les analyses proposées n’élèvent pas le niveau d’abstraction. La question de quels métriques pour quelles analyses est toujours d’actualité. Du point de vue d’un système de workflow pour l’analyse de traces, il faut avancer vers une compréhension plus poussée des mécanismes et techniques permettant de bonnes performances, tout en assurant les propriétés de reproductibilité et de généricité.
Table des figures
2.1 Control-flow capturant le processus d’évaluation de papiers . . . 21
2.2 Dataflow capturant le processus de commande et gestion de repas . . 22
3.1 Extrait de trace au format LTTng . . . 31
3.2 Représentation des événements dans Framesoc . . . 32
3.3 Représentation des quatre natures d’événements . . . 33
3.4 Représentation sans et avec sémantique . . . 34
3.5 Exemple de connexion entre deux modules . . . 36
3.6 Mécanismes de flux de données . . . 36
3.7 Modes de transfert des données . . . 37
3.8 Workflow abstrait de l’analyse générique d’un système Linux . . . 39
3.9 La collecte de trace pour la caractérisation générique . . . 40
4.1 Filtrage des événements SoftIRQ selon leur durée. . . 48
4.2 Filtrage des événements TSrecord selon la durée entre deux appels consécutifs. . . 49
4.3 Corrélation visuelle pourUnicast . . . 50
4.4 Corrélation visuelle pourTSrecord . . . 51
4.5 Corrélation peu lisible due à une grande différence du nombre d’évé-nements entre les deux ensembles. . . 53
4.6 En bleu, zones aux alentours des anomalies, elles-mêmes représentées par des barres verticales . . . 53
4.7 Architecture logicielle de Framesoc . . . 55
4.8 Exemple de paramètres d’entrée . . . 56
4.9 Exemple de résultat par corrélation avec découpage régulier . . . 57
4.10 Exemple de résultat par corrélation avec découpage non régulier . . . 58
7 – Table des figures
5.2 Exemple de module VisTrails . . . 61
5.3 Historique d’un workflow dans VisTrails. . . 62
5.4 Module de manipulation de trace dans VisTrails . . . 64
5.5 Workflow décrivant l’analyse via une base de données dans VisTrails. 65 5.6 Exemple d’exécution d’un workflow . . . 66
5.7 Diagramme UML de la partie ordonnancement . . . 68
5.8 Exemple de module avec la nouvelle interface de programmation . . . 69
5.9 Exemple d’exécution d’un workflow . . . 70
5.10 Diagramme UML des tâches . . . 71
5.11 Automate à états représentant l’exécution d’un module . . . 71
5.12 Analyse d’une trace d’exécution en utilisant le streaming . . . 72
5.13 Création d’un workflow d’analyse via une interface programmatique . 73 6.1 Représentation du buffer circulaire . . . 79
6.2 Exemple d’instanciation d’un workflow . . . 79
6.3 Création d’un sous-workflow dans un module . . . 80
6.4 Workflow principal de l’analyse . . . 84
6.5 Détail du sous-workflow GetPerfValues . . . 84
6.6 Détail du sous-workflow PerfAllRuns . . . 85
6.7 Répartition de l’utilisation du noyau du benchmark compress-gzip . 89 6.8 Catégorisation des événements noyau pour les 10 benchmarks . . . . 90
6.9 Ratio du temps passé en mode utilisateur et noyau . . . 90
6.10 Utilisation des processeurs en moyenne sur 32 exécutions . . . 91
6.11 Utilisation des processeurs pour une itération . . . 92
6.12 Profile mémoire construit à partir des allocations . . . 93
6.13 Ratio des instructions de calcul et de mémoire . . . 94
6.14 Utilisation du noyau pour les 10 benchmarks . . . 95
6.15 Ratio du temps passé en mode utilisateur et noyau . . . 96
6.16 Utilisation des différents processeurs pour une itération . . . 97
6.17 Ratio des instructions de calcul et de mémoire . . . 98
6.18 Comparaison des profils mémoire Juno et poste de travail . . . 99
6.19 Variation du score des benchmarks selon les configurations (x86) . . . 102
Liste des tableaux
2.1 Synthèse des outils d’exploitation de traces. . . 20
2.2 Synthèse des outils de workflow. . . 26
5.1 Temps d’exécution du workflow selon plusieurs configurations . . . 74
6.1 Répartition des benchmarks par familles dans PTS . . . 81
6.2 Liste des benchmarks utilisés . . . 82
6.3 Exemples de scores PTS . . . 82
6.4 Catégorisation des tracepoints du noyau . . . 86
6.5 Présentation des familles observées . . . 89
6.6 Mémoire maximum et appels inutiles à la fonction free . . . 92
6.7 Résultats pour l’utilisation noyau du benchmark compress-gzip . . . 94
6.8 Analyse mémoire pour la carte Juno (ARM) . . . 98
7 – Liste des tableaux
Bibliographie
[1] Apache Storm. http://storm.apache.org.
[2] ARM64 Juno. http://www.arm.com/products/tools/ development-boards/.
[3] Correlation (in statistics). a.v. prokhorov (originator), encyclopedia of mathematics. http://www.encyclopediaofmath.org/index.php?title= Correlation_(in_statistics)&oldid=11629.
[4] Framesoc. https://github.com/soctrace-inria/framesoc.
[5] Ftrace. https://www.kernel.org/doc/Documentation/trace/ftrace.txt. [6] Intel VTune. https://software.intel.com/en-us/
intel-vtune-amplifier-xe. [7] LTTng. http://lttng.org.
[8] Nvidia TegraK1. http://www.nvidia.com/object/ jetson-tk1-embedded-dev-kit.html.
[9] Paraver. http://www.bsc.es/computer-sciences/performance-tools/ paraver/general-overview.
[10] Perf. https://perf.wiki.kernel.org/index.php/Main_Page. [11] Phoronix Test Suite. http://www.phoronix-test-suite.com/. [12] Projet R. http://www.r-project.org/.
[13] Projet SoC-TRACE. http://www.minalogic.com/fr/projet/soc-trace. [14] Projet SoC-Trace. http://soc-trace.minalogic.net.
[15] Strace. https://en.wikipedia.org/wiki/Strace. [16] STWorkbench. http://stlinux.com/stworkbench/. [17] TraceCompass. http://tracecompass.org.
7 – Bibliographie
[19] Ieee standard glossary of software engineering terminology. IEEE Std 610.12-1990, pages 1–84, Dec 1990.
[20] Measuring Computer Performance : A Practitioner’s Guide. Cambridge Uni-versity Press, New York, NY, USA, 2000.
[21] Luay Alawneh and Abdelwahab Hamou-Lhadj. MTF : A Scalable Exchange Format for Traces of High Performance Computing Systems. 2011 IEEE 19th International Conference on Program Comprehension, pages 181–184, jun 2011. [22] JoseBacelar Almeida, MariaJoao Frade, JorgeSousa Pinto, and Simao Melo de Sousa. An overview of formal methods tools and techniques. In Rigorous Software Development, Undergraduate Topics in Computer Science, pages 15– 44. Springer London, 2011.
[23] Dieter An Mey, Scott Biersdorff, Christian Bischof, Kai Diethelm, Dominic Eschweiler, Michael Gerndt, Andreas Knüpfer, Daniel Lorenz, Allen D. Ma-lony, Wolfgang E Nagel, Yury Oleynik, Christian Rössel, Pavel Saviankou, Dirk Schmidl, Sameer S. Shende, Michael Wagner, Bert Wesarg, and Felix Wolf. Score-P – A Unified Performance Measurement System for Petascale Applica-tions. In Proc. of the CiHPC : Competence in High Performance Computing, HPC Status Konferenz der Gauß-Allianz e.V., Schwetzingen, Germany, June 2010, number June 2010, pages 85–97. Springer, 2012.
[24] Adam Barker and Jano Van Hemert. Scientific Workflow : A Survey and Re-search Directions. Proceedings of the 7th International Conference on Parallel Processing and Applied Mathematics, pages 746–753, 2008.
[25] Friedrich L. Bauer. From specifications to machine code : Program construction through formal reasoning. In Proceedings of the 6th International Conference on Software Engineering, ICSE ’82, pages 84–91, Los Alamitos, CA, USA, 1982. IEEE Computer Society Press.
[26] Christian Bienia and Sanjeev Kumar. PARSEC vs. SPLASH-2 : A quantitative comparison of two multithreaded benchmark suites on Chip-Multiprocessors.
2008 IEEE International Symposium on Workload Characterization, pages 47– 56, oct 2008.
[27] Steven P Callahan, Juliana Freire, Emanuele Santos, Carlos Scheidegger, Clau-dio T Silva, and Huy T Vo. VisTrails : Visualization meets Data Management. In Proceedings of the 2006 ACM SIGMOD International Conference on Mana-gement of Data, pages 745–747, 2006.
[28] Fernando Chirigati, Dennis Shasha, and Juliana Freire. ReproZip : Using Pro-venance to Support Computational Reproducibility. In USENIX Workshop on the Theory and Practice of Provenance, 2013.
[29] Leonaxdo Dagum and Ramesh Menon. OpenMP : An Industry Standard API for Shared-Memory Programming. Computational Science Engineering, IEEE, 5 :46–55, 1998.
[30] Andrew Davison. Automated capture of experiment context for easier repro-ducibility in computational research. Computing in Science and Engineering, 14(4) :48–56, 2012.
– [31] Ewa Deelman, Gurmeet Singh, Mei-hui Su, James Blythe, Yolanda Gil, Carl
Kesselman, G Bruce Berriman, John Good, Anastasia Laity, Joseph C Jacob, and Daniel S Katz. Pegasus : a Framework for Mapping Complex Scienti-fic Workflows onto Distributed Systems Decisions that need to take place in Workflow Mapping. Scientific Programming, 13(3), 2005.
[32] Mathieu Desnoyers. Low-Impact Operating System Tracing. PhD thesis, 2009. [33] Mathieu Desnoyers and Michel R Dagenais. The LTTng tracer : A Low Im-pact Performance and Behavior Monitor for GNU/Linux. In Ottawa Linux Symposium, 2006.
[34] Andi Drebes, Antoniu Pop, Karine Heydemann, Albert Cohen, and Natha-lie Drach-temam. Aftermath : A graphical tool for performance analy-sis and debugging of fine-grained task-parallel programs and run-time sys-tems. In7th workshop on Programmability Issues for Heterogeneous Multicores (MULTIPROG-2014), number 1, pages 1–13, 2014.
[35] Ulrich Drepper and Red Hat. What Every Programmer Should Know About Memory. 2007.
[36] Anchor Fastener. VISMASHUP : Streamlining the Creation of Custom Visua-lization Applications. Online, (October), 2009.
[37] Jean-daniel Fekete. Software and Hardware Infrastructures for Visual Analytics.
IEEE Computer, 43(8) :1–7, 2013.
[38] I. Foster, J. Vockler, M. Wilde, and Y. Zhao. Chimera : a virtual data system for representing, querying, and automating data derivation. Proceedings 14th International Conference on Scientific and Statistical Database Management, 2002.
[39] Edgar Gabriel, Graham E Fagg, George Bosilca, Thara Angskun, Jack J Don-garra, Jeffrey M Squyres, Vishal Sahay, Prabhanjan Kambadur, Brian Barrett, Andrew Lumsdaine, Ralph H Castain, David J Daniel, Richard L Graham, and Timothy S Woodall. Open MPI : Goals, Concept, and Design of a Next Genera-tion MPI ImplementaGenera-tion. In11th European PVM/MPI Users’ Group Meeting, pages 97–104, 2004.
[40] Markus Geimer, Felix Wolf, Brian J N Wylie, Erika Abraham, Daniel Becker, and Bernd Mohr. The Scalasca Performance Toolset Architecture. In In Inter-national Workshop on Scalable Tools for High-End Computing (STHEC, num-ber 01, pages 702–719, 2008.
[41] Diimitrios Georgakopoulos, Mark Hornick, and Amit Sheth. An Overview of Workfow Management : From Process Modeling to Work ow Automation In-frastructure. Work, 153 :119–152, 1995.
[42] Yolanda Gil, Ewa Deelman, Mark Ellisman, Thomas Fahringer, Geoffrey Fox, Dennis Gannon, Carole Goble, Miron Livny, Luc Moreau, and Jim Myers. Exa-mining the challenges of scientific workflows. Computer, 40(12) :24–32, 2007. [43] Francis Giraldeau, Julien Desfossez, David Goulet, Michel Dagenais, and
Ma-thieu Desnoyers. Recovering system metrics from kernel trace. OLS (Ottawa Linux symposium), pages 109–116, 2011.
7 – Bibliographie
[44] Abdelwahab Hamou-lhadj, Syed Shariyar Murtaza, Waseem Fadel, Ali Mehra-bian, Mario Couture, and Raphael Khoury. Software Behaviour Correlation in a Redundant and Diverse Environment Using the Concept of Trace Abstraction. pages 328–335, 2013.
[45] IEEE. Computer July 2013. (July 2013), 2013.
[46] R Jain. The Art Of Computer Systems Performance Analysis. Wiley India Pvt. Limited, 1991.
[47] Ajay Joshi, Student Member, Aashish Phansalkar, and Student Member. Mea-suring Benchmark Similarity Using Inherent Program Characteristics. IEEE
TRANSACTIONS ON COMPUTERS, 55(6) :769–782, 2006.
[48] Jacques Chassin De Kergommeaux and Benhur De Oliveira Stein. Pajé : An Extensible Environment for Visualizing Multi-threaded Programs Executions. In Roland Bode, Arndt and 0002, Thomas Ludwig and Karl, Wolfgang and Wismüller, editor, Euro-Par, pages 133–140. Springer, 2000.
[49] Jihie Kim, Yolanda Gil, and Marc Spraragen. A Knowledge-Based Approach to Interactive Workflow Composition. Icaps - 04, (Icaps 04), 2004.
[50] Andreas Knüpfer, Ronny Brendel, Holger Brunst, Hartmut Mix, and Wolf-gang E Nagel. Introducing the Open Trace Format (OTF). In Jack Alexandrov, Vassil N. and van Albada, G. Dick and Sloot, Peter M. A. and Dongarra, editor,
International Conference on Computational Science (2), pages 526–533, 2006. [51] Andreas Knüpfer, Holger Brunst, and Ronny Brendel. Open Trace Format
Specification. 2009.
[52] Andreas Knüpfer, Holger Brunst, Jens Doleschal, Matthias Jurenz, Holger