Conception flexible d'analyses issues d'une trace système

Les logiciels deviennent de plus en plus complexes. Avec l'avènement de l'informatique embarquée, la limitation des ressources les contraint à s'exécuter en économisant le temps, la mémoire et l'énergie. Dans ce contexte, les développeurs ont besoin d'outils pour déboguer et optimiser les programmes qu'ils écrivent. Parmi ces outils, le traçage est une solution particulièrement adaptée qui enregistre l'occurrence d'événements, en interagissant peu avec l'exécution. Elle permet de mettre en évidence les causes de bogues ou les goulots d'étranglement qui ralentissent le programme. LTTng est un traceur focalisé sur les performances : grâce à des structures de données propres à chaque coeur et à des verrous non-bloquants, l'enregistrement d'un événement prend moins d'une microseconde sur une machine récente. Ce délai est toutefois nonnégligeable, il empêche de tracer un nombre arbitraire de points sans affecter les performances. De plus, le code et les données liées au traçage sont stockés dans l'espace mémoire du processus étudié, ce qui cause un impact sur son exécution. L'utilisation de blocs matériels dédiés au débogage pallie à ces limitations. Il existe une multitude de ces circuits, présents sur la plupart des processeurs du marché, à des fins de débogage et de profilage. En réutilisant leurs capacités à des fins de traçage, nous proposons de soulager la partie logicielle d'outils comme LTTng, et ainsi d'accroître leurs performances. Pour ce faire, nous utilisons les modules matériels STM, ETM et ETB de la suite CoreSight sur les processeurs ARM,ainsi que BTS sur les processeurs x86 d'Intel. Certains offrent une fonctionnalité de traçage d'exécution, c'est-à-dire d'enregistrement de la liste des instructions exécutées ; d'autres fournissent des ressources spécialisées pour l'estampillage de temps, l'envoi de messages sur des canaux dédiés, et le stockage de traces. Dans ce mémoire, nous proposons des implémentations de traçage logiciel s'aidant du matériel pour être moins intrusifs que les outils purement logiciels. Nous visons à réduire le surcoût en temps engendré par le traçage, c'est-à-dire le nombre de cycles ajoutés à une exécution normale, tout en gardant le même détail d'information que fournit une trace. Nous montrons que l'utilisation conjointe des modules STM et ETB pour faire transiter les traces par des circuits matériels dédiés économise la mémoire du processus et que la durée des points de trace est divisée par dix par rapport à LTTng. En utilisant ETM et ETB, le surcoût du traçage est lui aussi réduit : entre -30% et -50% par rapport à notre traceur de référence. En revanche, les capacités du traceur d'exécution ETM limitent notre système à seulement quelques points de trace enregistrables dans tout le programme. Finalement, l'utilisation de BTS sur les processeurs Intel est aussi plus efficace : les points de trace sont presque deux fois plus rapides que ceux de LTTng. Cependant, ce système ne permet pas de choisir quels événements tracer : tous les branchements pris par le processeur sont enregistrés. Cette lourdeur rend BTS inutilisable pour faire du traçage d'événements ; néanmoins pour du traçage d'exécution, la ré-implémentation que nous proposons est 65% plus rapide que celle de Perf, l'outil par défaut sous Linux.

Abstract

Software is becoming increasingly complex. With the advent of embedded computing, resource limitations force it to run in a way saving time, memory and energy. In this context, developers need tools to debug and optimize the programs they write. Among these tools, tracing is a particularly well suited solution that records the occurrence of events, while minimally interacting with the execution. It allows to identify the causes of bugs or bottlenecks that slow down the program. LTTng is a tracer focused on performance: through per-core data structures and nonblocking locks, recording an event takes less than one microsecond on a typical computer. However, this delay is not negligible, and tracing an arbitrary number of points is not possible without affecting performance. In addition, the code and data related to tracing are stored in the memory space of the process being studied, causing an impact on its execution. The use of dedicated debug hardware blocks overcomes these limitations. There are a multitude of these circuits, present on most processors on the market, for of debugging and profiling purposes. By reusing their capacity for tracing purposes, we propose to alleviate the software part of tracing tools such as LTTng, and thereby increase their performance. To do this, we use STM, ETM and ETB hardware modules from the CoreSight suite on ARM processors, as well as BTS on Intel x86 processors. Some offer an execution tracing feature, i.e. recording the list of executed instructions; others provide specialized resources for timestamping, transfering messages on dedicated channels, and storing traces. In this thesis, we propose implementations of software tracing that take advantage of hardware to be less intrusive than pure-software tools. We aim to reduce the time overhead induced by tracing, i.e. the number of cycles added to a normal execution, while keeping the same detailed information as a trace provides. We show that the combined use of STM and ETB modules to send traces through dedicated hardware circuits saves process memory and that each tracepoint duration is divided by ten as compared to LTTng. Using ETM and ETB, the overhead of tracing is also reduced: between -30% and -50% as compared to our reference tracer. However, the capacity of the ETM execution tracer limits our system to only a few recordable tracepoints throughout the program. Finally, the use of BTS on Intel processors is also more efficient: tracepoints are almost two times faster than LTTng. However, it is not possible to choose which events to trace with this system: all branches taken by the processor are stored. This limitation makes BTS unusable for event tracing; however, for execution tracing the re-implementation we offer is 65% faster than Perf, the default tool on Linux.