Traçage de systèmes linux multi-coeurs en temps réel
Pourquoi ce travail est dans la base
Une base qui oublie comment elle a trouvé un travail ne peut pas être vérifiée. Voici les voies qui ont admis celui-ci.
Notice bibliographique
Résumé
RESUME Le tracage est une methode d’analyse de plus en plus populaire compte tenu de la precision des donnees qu’il permet de reunir concernant les activites d’un systeme. Nombre de systemes demandent cependant aujourd’hui de fonctionner dans des conditions restreintes : c’est le cas des systemes temps reel. Ces systemes reposent sur le respect d’echeances dans le traitement de donnees. Autrement dit, une donnee exacte n’aura de valeur dans un systeme de ce type qu’a condition qu’elle soit obtenue dans les delais, sans quoi le systeme sera considere defaillant. Ces conditions excluent par consequent tout outil d’analyse impactant de maniere significative la latence et les performances du systeme. Le tracage repose sur l’ajout de points de trace au sein de l’application ou du systeme d’exploitation trace. Ces derniers vont generer des evenements lorsqu’ils sont atteints durant l’execution et ainsi permettre de suivre l’etat d’un systeme au fur et a mesure de son execution. Cependant, la generation de ces donnees implique une modification dans le deroulement normal de l’application ou du systeme trace, et par consequent un impact. Il devient alors important de pouvoir quantifier cet impact de maniere a savoir sous quelles conditions une application temps reel pourra ou ne pourra pas etre tracee, autrement dit, de savoir si l’ajout de ce delai de traitement rendra le systeme defaillant, et par consequent inadequat au tracage. L’objectif de cette recherche est de montrer qu’il est tout a fait possible d’utiliser le tracage pour analyser de telles applications, et ce avec un impact en terme de latence que nous souhaitons quantifier pour le pire cas. Pour ce faire, nous allons definir un environnement de travail temps reel en etudiant les divers systemes et configurations speciales mis a disposition. Ensuite nous verrons quels sont les outils permettant de valider la qualite de notre environnement de travail et quel est leur fonctionnement. Nous comparerons par la suite les differents outils mettant a disposition des traceurs, et lesquels parmi eux nous permettent de correler des traces du noyau et de l’espace utilisateur. Une fois l’environnement defini et verifie et l’outil de tracage choisi, notre methode experimentale reposera sur un etalonnage du systeme temps reel permettant par la suite d’evaluer l’impact du traceur sous differents angles a l’aide de la creation de different scenarios d’analyse. Cette methode experimentale prendra en compte la latence ajoutee sur le systeme par l’instrumentation, le tracage mais aussi la qualite des traces obtenues. Ces elements seront les marqueurs de qualite du tracage dans des conditions temps reel. L’hypothese servant de point de depart de ce travail est qu’en isolant le fonctionnement du traceur de celui de l’application temps reel tracee, l’impact de l’outil de tracage sur l’application pourra etre radicalement reduit. Les resultats de ce travail sont la decouverte et l’integration aux outils existants d’un modele pour supprimer les communications entre l’application tracee et le traceur durant la periode active de tracage, permettant ainsi de n’ajouter qu’une interference minimale sur l’execution normale de l’application, permettant ainsi de rendre le tracage apte a fonctionner dans nombre de conditions temps reel, du moment que le delai maximal qu’il ajoute entre dans l’echeance de celle-ci. De plus, l’outil npt cree comme outil d’etalonnage et d’analyse de l’impact a evolue au fur et a mesure de nos recherches et est maintenant un logiciel disposant de differentes options pour simuler de multiples scenarios d’execution d’une application temps reel. Enfin, la methodologie d’analyse de l’impact du tracage sur le systeme temps reel constitue elle aussi un des resultats de cette etude. Le resultat final est que l’utilisation du tracage pour une application temps reel s’executant dans l’espace utilisateur est viable pour la plupart des systemes temps reel avec une latence ajoutee de seulement quelques microsecondes.----------ABSTRACT Tracing is an analysis method increasingly popular. It provides a lot of information of high precision about a system or application. However, many systems need to operate under restricted conditions. This is the case of real-time systems. These systems are based on meeting deadlines in data processing. In other words, accurate data will only have a value if we can poduce it in a timely fashion, otherwise we will consider the system as defective. These conditions therefore exclude any analysis tool which could impact significantly the system latency or performance. Tracing is based on the addition of tracepoints directly in the application or operating system source code. There tracepoints will generate events when they are reached as part of the execution, and allow to monitor the system or application state during its run. Still, the generation of this data involves a change in the normal course of the traced system, hence an impact. It then becomes important to quantify this impact in order to know the conditions for tracing a real-time application, in other words, to know whether the added latency will invalidate the real-time condition, hence force to consider tracing as inedequate or not. The objective of this research is to prove that it is possible to use tracing to analyze such applications, thus quantifying the maximum impact in terms of latency. In order to do that, we will define a real-time work environment by studying the various systems and special configurations available, then we will see what tools allow to validate the quality of our work environment and how they work. We will then compare the various tracing tools and identify which allow us to correlate the kernel and userspace traces. Once we have setup and verified our real-time environment and selected our tracing tool, our experimental method will be based on real-time system calibration to subsequently assess the impact of the tracer from different use cases, using different analysis scenarios. This experimental method will take into account the latencies added by the instrumentation and the tracing of the system, but also the quality of the generated traces. These elements will be considered as quality markers of real-time tracing. The hypothesis serving as starting point for this work is that, by isolating the work of the tracer from that of the real-time application, the impact of the tracing tool on the application can radically be reduced. The results of this work are the discovery and integration in existing tools of a model to remove the direct connections, between the traced application and the tracer, while the tracing operations are active. This allows to only add a minimal interference to the normal execution of the application, thereby making tracing able to operate multiple real-time cases, as long as the maximum latency added can be supported by the traced application. In addition, the npt tool created as the calibation and impact analysis tool has evolved during our research and now offers options allowing to simulate multiple execution scenarios of real-time applications. Finally, the real-time tracing impact analysis methodology we developed is also one of the results of this study. The final result is that using tracing to analyze real-time applications running in userspace is a valid and good option for most real-time systems, adding latencies in the low microsecond range.
Récupéré en direct depuis OpenAlex et désinversé. Les résumés ne sont pas conservés dans cette base de données : les index inversés représentent 8,6 Go des 9,3 Go de texte de la base, et le serveur dispose de 13 Go libres.
Prédiction distillée sur la base complète
Imitation des enseignantsNi prévalence calibrée, ni vérité terrain. Validation humaine à venir. Apprise à partir de 10 348 étiquettes directes de Codex et de 10 348 étiquettes directes de Gemma. Le mode candidate est l'union des têtes enseignantes seuillées; le consensus est leur intersection. Ces sorties portent le statut machine_predicted_unvalidated et ne sont ni des étiquettes humaines ni des étiquettes directes de modèles de pointe.
Scores Codex et Gemma par catégorie
| Catégorie | Codex | Gemma |
|---|---|---|
| Métarecherche | 0,003 | 0,001 |
| Méta-épidémiologie (sens strict) | 0,001 | 0,001 |
| Méta-épidémiologie (sens large) | 0,001 | 0,001 |
| Bibliométrie | 0,001 | 0,001 |
| Études des sciences et des technologies | 0,001 | 0,000 |
| Communication savante | 0,001 | 0,003 |
| Science ouverte | 0,003 | 0,001 |
| Intégrité de la recherche | 0,001 | 0,001 |
| Charge utile insuffisante (le modèle a refusé de juger) | 0,000 | 0,001 |
Scores machine (provisoires)
Les deux têtes enseignantes du modèle étudiant, lues sur ce travail. Un score ordonne la base pour la relecture; il n'affirme jamais une catégorie, et le statut de validation accompagne chaque rangée tel quel.
Scores de référence d'un modèle non mature (critères de maturité non atteints, 7 itérations). Un score ordonne; il n'affirme jamais une catégorie.
score_only:v0-immature-baseline · tel quel depuis la passe de notation : score_only signifie que le nombre peut ordonner les travaux, et qu'aucune étiquette de catégorie n'en découle