D eveloppement d’outils de trace d’ex ecution pour des syst emes …raphaelbeamonte.com/files/TN10.pdf · 2016. 3. 3. · Université de technologie de Troyes z 12 rue Marie Curie

Uni

vers

ité d

e te

chno

logi

e de

Tro

yes

12

rue

Mar

ie C

urie

B

P 20

60

100

10 T

roye

s ced

ex

page de garde.qxd 01/04/2004 16:25 Page 1

Developpement d’outils de trace d’execution pourdes systemes embarques et mobiles multicœurs

sous Linux

TN10 - Projet de fin d’etudes

Systemes d’Information et Telecommunications

Technologies Mobiles et Systemes Embarques

Raphael BEAMONTE

Resume : Ce projet de fin d’etudes s’est deroule a l’Ecole Polytechnique de Montreal(EPM), au sein du laboratoire Distributed Open Reliable Systems Analysis Lab (DOR-SAL) du departement de Genie Informatique et Genie Logiciel (GIGL).Celui-ci a consiste en des recherches sur les systemes temps reel et le moyen de testerleurs performances de facon a pouvoir ameliorer l’outil de trace d’execution du labora-toire. Ces ameliorations ont pour but qu’il puisse tracer de tels systemes sans en impacterles performances.

Les differentes phases de travail successivement realisees sont :– Decouverte et apprentissage des notions liees au tracage systeme ;– Prise en main de l’outil Linux Trace Toolkit next generation (LTTng) developpe par

le laboratoire et des outils associes ;– Revue de litterature sur les systemes temps reel et les notions memes sur lesquelles

sont bases ces systemes ;– Tests des outils existants pour analyser les performances temps reel d’un systeme ;– Developpement d’un nouvel outil d’analyse de performances temps reel en collaboration

avec un partenaire du projet.

Mots cles : Recherche appliquee & developpement, 14 – Services non marchands, Informatique,Logiciels – Recherche

Ecole Polytechnique de Montreal2900, boulevard Edouard Montpetit

Montreal, QC H3T 1J4

Sous la responsabilite entreprise de Michel DagenaisSous le tutorat UTT de Manuel Zacklad

Soutenu le mardi 21 fevrier 2012 pour l’obtention du diplome d’Ingenieur

Universite de technologie de TroyesAutomne 2011

« Le temps murit toutes choses ;par le temps, toutes choses viennent en evidence ;

le temps est pere de verite. »

Francois Rabelais (le Tiers Livre – 1546)Medecin et ecrivain humaniste francais de la Renaissance

I

Remerciements

Avant tout developpement sur cette experience en recherche, il est opportun de com-mencer ce rapport par des remerciements, autant a ceux qui m’ont accorde leur confianceet permis d’evoluer et d’apprendre, qu’a ceux qui ont contribue a une bonne ambiancede travail.

Aussi, je remercie Michel Dagenais, mon responsable de projet et directeur de re-cherche, pour m’avoir permis de rejoindre son laboratoire et m’avoir accorde sa confiancedes le premier jour.

De meme, je tiens a remercier Jean Dansereau, directeur des etudes superieures del’Ecole Polytechnique de Montreal, pour sa confiance en mon avenir et son soutien, etJulie Defretin, conseillere aux etudiants internationaux, pour toute l’aide qu’elle m’aapportee dans mes demarches administratives compliquees.

Je remercie aussi Yannick Brosseau, associe de recherche au laboratoire DORSAL,qui a ete d’une grande aide depuis mon arrivee et m’a soutenu sans defaillir, m’aidantsouvent a orienter mes recherches.

Je remercie par ailleurs Manuel Zacklad, mon tuteur de l’Universite de technologiede Troyes, et Lucie Lourenco, gestionnaire des stages SIT, pour leur suivi de mon evo-lution durant ces six mois.

Je remercie de plus Florent Retraint, responsable du programme SIT a l’Univer-site de technologie de Troyes, Christelle Danau, assistante du programme SIT, MichelDoussot, responsable de la filiere TMSE, Timothee Toury, directeur de la formationet de la pedagogie, Guillaume Doyen, enseignant-chercheur, et Giorgio Lanzarone,Information Management Officer a la FAO of the UN, pour leur soutien indefectible, leurconfiance, et leurs conseils qui m’ont permis d’arriver jusqu’ici.

Enfin, je remercie toute l’equipe du laboratoire DORSAL pour leur accueil chaleureux,les reunions-bouffe, le partage des connaissances – y compris en ce qui concerne le parlerquebecois et la culture associee –, la bonne ambiance et leurs precieux conseils tout aulong de mon projet.

II

Sommaire

Remerciements II

Sommaire III

Table des figures V

Liste des tableaux VI

Introduction 1

1 Presentation de l’organisation d’accueil 21.1 L’Ecole Polytechnique de Montreal . . . . . . . . . . . . . . . . . . . . . 2

1.1.1 Historique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.1.2 L’embleme de Polytechnique . . . . . . . . . . . . . . . . . . . . . 4

1.2 Le departement de Genie Informatique et Genie Logiciel . . . . . . . . . 51.2.1 Historique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.3 Le Laboratoire d’Analyse de Systemes Repartis Ouverts et tres Disponibles 6

2 Linux Trace Toolkit next generation (LTTng) 72.1 Qu’est-ce que le tracage ? . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.1.1 Allegorie de la « boıte noire » . . . . . . . . . . . . . . . . . . . . 72.1.2 Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.2 Un premier ensemble d’outils : Linux Trace Toolkit (LTT) . . . . . . . . 82.3 La nouvelle generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.3.1 Version 0.x . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.3.2 Version 2.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.3.3 Cas pratique : enregistrer en seulement quelques minutes une trace

avec LTTng . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.3.3.1 Creation d’une session de tracage . . . . . . . . . . . . . 142.3.3.2 Activer des evenements a surveiller . . . . . . . . . . . . 142.3.3.3 Definir un contexte . . . . . . . . . . . . . . . . . . . . . 142.3.3.4 Demarrer le tracage . . . . . . . . . . . . . . . . . . . . 152.3.3.5 Arreter le tracage . . . . . . . . . . . . . . . . . . . . . . 152.3.3.6 Visualiser la trace . . . . . . . . . . . . . . . . . . . . . 15

2.4 Les entreprises impliquees dans le developpement . . . . . . . . . . . . . 16

III

SOMMAIRE

3 Projet de recherche 173.1 Un systeme temps reel . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173.2 Les systemes d’exploitation temps reel . . . . . . . . . . . . . . . . . . . 19

3.2.1 Approche micro-noyau (ou thin-kernel) . . . . . . . . . . . . . . . 193.2.2 Approche du temps reel dans le noyau standard Linux . . . . . . 20

3.3 Contraintes materielles et logicielles . . . . . . . . . . . . . . . . . . . . . 223.3.1 Un systeme inapte au temps reel . . . . . . . . . . . . . . . . . . 22

3.3.1.1 Les premiers tests : cyclictest . . . . . . . . . . . . . . . 223.3.1.2 Des tests materiels : hwlatdetect . . . . . . . . . . . . . 24

3.3.2 Un nouveau systeme plus adapte . . . . . . . . . . . . . . . . . . 253.4 Implementation d’un outil de test de non-preemption d’un processus de la

plus haute priorite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253.4.1 Le « shield CPU » . . . . . . . . . . . . . . . . . . . . . . . . . . 263.4.2 Programme d’analyse du respect de la non-preemption des proces-

sus de haute-priorite temps reel . . . . . . . . . . . . . . . . . . . 27

Conclusion 30

Annexes 32A. Enregistrements realises par hwlatdetect . . . . . . . . . . . . . . . . . . . 33B. Patch noyau pour le module hwlat detector 1.1.0 . . . . . . . . . . . . . . 35C. Configuration dynamique du noyau via sysctl . . . . . . . . . . . . . . . . 55D. Organisation de la recherche durant les 24 semaines de projet . . . . . . . 56E. Curriculum Vitae . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

Glossaire 58

Bibliographie 60

IV

Table des figures

1.1 La premiere Ecole Polytechnique de Montreal et son fondateur . . . . . . 41.2 L’embleme de l’Ecole Polytechnique de Montreal . . . . . . . . . . . . . . 5

2.1 Graphique des evenements dans LTT 0.9.5 . . . . . . . . . . . . . . . . . 92.2 Logo du logiciel LTTng . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.3 Capture d’ecran de la visualisation d’une trace avec LTTV . . . . . . . . 112.4 Capture d’ecran de la visualisation d’une trace avec le plugin Eclipse . . 112.5 Capture d’ecran de la visualisation d’une trace avec lttngtop . . . . . . . 12

3.1 Representation des etapes de fonctionnement d’un systeme temps reel . . 183.2 Approche micro-noyau pour le temps reel a contraintes strictes . . . . . . 203.3 Approche du noyau standard de linux avec preemption . . . . . . . . . . 213.4 Retour d’execution de cyclictest sur la station A moins d’une seconde apres

le debut . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233.5 Retour d’execution de cyclictest sur la station A, entre 1 et 2 secondes

apres le debut . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243.6 Resultat de hwlatdetect sur la station A . . . . . . . . . . . . . . . . . . 243.7 Retour d’execution de cyclictest sur la station B, apres plus de 10 000

cycles par processus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253.8 Resultat de hwlatdetect sur la station B . . . . . . . . . . . . . . . . . . 26

V

Liste des tableaux

1.1 Personnes inscrites au trimestre d’automne 2011 a l’Ecole Polytechniquede Montreal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

VI

Introduction

Afin de cloturer mes etudes d’ingenieur en Systemes d’Information et Telecommuni-cations a l’Universite de technologie de Troyes (UTT), un projet de fin d’etudes, appeleTN10 en interne, doit etre realise en fin de cursus dans notre specialite, autrement dit enTechnologies Mobiles et Systemes Embarques pour ma part.

Ce stage, d’une duree d’environ 6 mois, nous permet de nous preparer a notre futurposte d’ingenieur dans le milieu de l’industrie comme dans celui de la recherche, en met-tant a contribution nos competences afin de repondre a des problematiques de l’entrepriseou de l’organisation qui nous accueille.

Ainsi, du 12 septembre 2011 au 2 mars 2012, j’ai choisi de rejoindre le laboratoireDistributed Open Reliable Systems Analysis Lab (DORSAL), specialise dans les systemesrepartis ouverts et tres disponibles, qui est situe au sein de l’Ecole Polytechnique deMontreal, dans la ville eponyme. Contrairement a mon stage de milieu d’etudes, qui sederoulait dans l’industrie chez IBM France dans le domaine du conseil, ce projet de find’etudes etait tres lie par son sujet a mes interets pour l’avenir, et avait pour but dem’apporter une experience dans le domaine de la recherche en genie.

Ce rapport sur mes activites durant ce projet se composera de trois parties : je presen-terai tout d’abord de maniere generale l’organisation qui m’a accueilli, le logiciel developpepar le laboratoire, et enfin mes etapes de recherche et reflexions.

Finalement, je concluerai sur les lecons que je retire de cette experience en recherchedans le laboratoire DORSAL.

1

Chapitre 1

Presentation de l’organisationd’accueil

J’ai pu effectuer mon projet de fin d’etudes (TN10) dans la recherche au sein de l’EcolePolytechnique de Montreal (EPM), au Quebec. Durant cette periode de 24 semaines, j’aitravaille dans le laboratoire DORSAL.

Dans cette partie, je presenterai tout d’abord l’EPM, le departement de Genie In-formatique et Genie Logiciel (GIGL) puis le laboratoire DORSAL au sein duquel j’aievolue.

1.1 L’Ecole Polytechnique de Montreal

L’Ecole Polytechnique de Montreal (EPM) est la premiere ecole d’ingenierie franco-phone d’Amerique et l’un des plus importants etablissements d’enseignement et de re-cherche en genie au Canada, que ce soit par sa taille ou par la diversite de ses programmesd’enseignement [3]. C’est une universite publique qui dispose d’un budget annuel de fonc-tionnement de 200 millions de dollars canadiens (CAD), dont 72 millions de CAD enrecherche [6].

En automne 2011, 5 317 etudiants etaient inscrits en premier cycle (baccalaureat eningenierie, certificat, etc.), 1 194 en deuxieme cycle (maıtrise recherche ou cours, micro-programme, etc.), et 669 en troisieme cycle (doctorat, post-doc, etc.) (voir tableau 1.1).Chaque annee, environ 1 300 diplomes sont decernes [7], ce qui eleve a ce jour a 37 000le nombre de diplomes de l’EPM depuis sa fondation.

1.1.1 Historique

En 1873, afin de repondre aux besoins crees par la revolution industrielle, l’Ecole dessciences appliquees aux arts et a l’industrie est fondee par Urgel-Eugene Archambault 1

(voir figure 1.1(b)). Sept eleves se presentent a la premiere session en janvier 1874, tandisque les cours sont donnes dans une maison convertie de l’Academie du Plateau.

1. Urgel-Eugene Archambault (27 mai 1834 – 20 mars 1904) etait un instituteur et administrateur

scolaire, il a fonde l’EPM et en fut le premier principal et directeur [3, 25].

2

CHAPITRE 1. PRESENTATION DE L’ORGANISATION D’ACCUEIL

GradesRegimes Personnes inscrites

temps plein temps partielfemmes hommes Totaux

femmes hommes femmes hommes

1er cycleBaccalaureat 838 3071 56 258 894 3329 4223Certificat 32 135 77 417 109 552 661Programme Court 52 167 2 4 54 171 225Autres 1er cycle 17 79 12 58 29 137 166Hors faculte 9 6 27 6 36 42Total 1er cycle 939 3461 153 764 1092 4225 5317

2e cycleD.E.S.S. 27 95 25 57 52 152 204Maıtrise cours 56 134 19 75 75 209 284Maıtrise recherche 141 335 141 335 476Microprogramme 1 2 1 3 1 4Autres 2e cycle 3 14 21 55 24 69 93Hors faculte 2 40 91 40 93 133Total 2e cycle 228 580 107 279 335 859 1194

3e cycleDoctorat 171 461 171 461 632Post-doc 5 30 5 30 35Autres 1 1 1 1 2Hors faculte 0 0 0Total 3e cycle 171 461 6 31 177 492 669

Total 1338 4502 266 1074 1604 5576 7180

Tableau 1.1 – Personnes inscrites au trimestre d’automne 2011 a l’Ecole Polytechniquede Montreal, pour chaque grade par cycle [8]

En 1875, l’Ecole des sciences appliquees aux arts et a l’industrie demenage dans unedifice de la Commission des ecoles catholiques de Montreal (voir figure 1.1(a)) et devientofficieusement l’Ecole Polytechnique de Montreal [12]. Elle est reconnue officiellement parle gouvernement provincial du Quebec un an plus tard, et obtient l’autorisation de de-cerner le titre d’ingenieur et le grade de bachelier es sciences appliquees : elle etait alorsla premiere ecole francophone d’ingenieurs en Amerique. En 1887, l’EPM passe sous lajuridiction de l’Universite Laval a Quebec (ULQ) 2 et est affiliee a sa nouvelle faculte desarts a Montreal. Le 12 janvier 1895, une sanction de la loi cree la Corporation de l’EcolePolytechnique de Montreal, lui conferant son autonomie administrative et financiere. Des1920, alors que l’Universite de Montreal (UdeM) 3 obtient a son tour une charte provin-ciale, l’EPM lui fut affiliee tout en conservant son autonomie. En juillet 1958, l’EPMemmenage dans ses nouveaux locaux adjacents a l’Universite de Montreal sur le Mont-Royal 4.

2. Le site de l’Universite Laval a Quebec (ULQ) est disponible sur http://www.ulaval.ca/3. Le site de l’Universite de Montreal (UdeM) est disponible sur http://www.umontreal.ca/

4. Les coordonnees GPS de l’EPM sont les suivantes : 45.505°N 73.614°W

3

http://www.ulaval.ca/

http://www.umontreal.ca/


(a) La premiere ecolePolytechnique, de 1875 a1904

(b) Urgel-EugeneArchambault

Figure 1.1 – La premiere Ecole Polytechnique de Montreal et son fondateur

L’EPM est une des plus importantes et des plus anciennes institutions d’enseignementdu genie au Canada. Pres de 240 professeurs et 800 employes travaillent a l’EPM pourassurer la formation de pres de 6 900 etudiants inscrits aux trois cycles d’enseignement eta la formation continue, dont 1 800 aux etudes superieures. Le travail de ces professeurs etemployes permet la remise annuelle de plus de 900 diplomes, y compris les certificats [6].

De plus, l’EPM offre l’eventail de specialites pour la formation d’ingenieur le pluslarge [5], et realise pres du quart de la recherche universitaire en ingenierie au Quebec.Disposant de 60 unites de recherche, elle poursuit a ce jour une activite parmi les plusintenses au Canada, avec 17 Chaires industrielles et 24 Chaires de recherche du Canada.L’EPM compte plus de 250 ententes avec des etablissements a travers le monde, et 22%de sa population etudiante provient de l’etranger.

1.1.2 L’embleme de Polytechnique

Peu de traces des origines de l’embleme de l’EPM ont ete retrouvees. La plus anciennerepresentation remonte a 1905 : le plancher du hall d’entree de l’edifice de la rue Saint-Denis qui abritait l’ecole est dote d’une abeille encerclee d’une roue dentee, cette derniereetant traversee par une poutre en I [6].

On identifie l’abeille comme etant la representation du travail planifie et organise del’ingenieur, tandis que la poutre en I illustre possiblement le genie civil, premiere disciplinedu genie enseignee a l’EPM. La roue dentee, quant a elle, semble faire reference a l’essorindustriel du 19e siecle durant lequel les ingenieurs allaient jouaient un role majeur. Enfin,les couronnes de laurier, encadrant le tout, representent l’excellence (voir figure 1.2(b)).

La devise « Ut tensio sic vis » accompagne l’embleme. Celle-ci est tiree d’une loide la resistance des materiaux, appelee loi de Hooke. Sa traduction technique signifie« l’allongement est proportionnel a la force. » De facon figurative, elle signifie que « leresultat est proportionnel a l’effort. »

4


(a) Interpretation de Jordi Bo-net (Sculpture murale, Aluminium,1977)

(b) Version actuelle

Figure 1.2 – L’embleme de l’Ecole Polytechnique de Montreal

1.2 Le departement de Genie Informatique et Genie

Logiciel

Le departement de GIGL est responsable des programmes eponymes. Le programme degenie informatique, en plus de la formation classique, offre deux orientations (multimediaet innovation technologique) ainsi que deux concentrations. Les deux orientations sontaussi offertes par le programme de genie logiciel.

Le departement GIGL a aussi pour responsabilite la formation aux cycles superieursau niveau du diplome d’etudes superieures, de la maıtrise cours (M.Ing.), de la maıtriserecherche (M.Sc.A), de la maıtrise modulaire et du doctorat (Ph.D.).

1.2.1 Historique

C’est en 1907 que l’histoire du departement debute avec la creation d’un laboratoired’electricite au sein de l’EPM. Les fondements du futur departement de Genie Electriquede l’ecole sont desormais poses, departement dont sera issu, 94 ans plus tard, le departe-ment de Genie Informatique.

Jusqu’a 1958, l’option mecanique-electricite etait l’une des options de formation lesplus demandees a l’EPM. Le departement de Genie Electrique est cree en 1958 ; il contri-buera durant les 40 annees suivantes a la creation de plusieurs nouvelles entites de l’Ecole,dont le departement de Genie Physique, le Service Informatique et l’Institut de Genie Bio-medical.

Au debut des annees 90, l’interet pour le genie informatique grandissant autant aupresdes etudiants a venir que des professeurs, le departement de Genie Electrique devient leDepartement de Genie Electrique et de Genie Informatique (DGEGI). Cependant, lacroissance des demandes pour etudier en genie electrique comme en genie informatiqueetant continue, l’Ecole choisi de separer le departement DGEGI en deux departementsdistincts, permettant de ce fait au genie electrique de reprendre son nom original. C’estainsi que le 1er juin 2001, le departement de Genie Informatique est cree a partir des

5


effectifs du DGEGI. Lors de sa creation, ce nouveau departement est deja l’un des plusimportants departements de genie de l’Ecole, avec pres de 1 000 etudiants.

En 2001, le programme de Genie Logiciel est cree, mais c’est environ cinq ans plustard que le departement de Genie Informatique deviendra le departement de Genie In-formatique et Genie Logiciel.

1.3 Le Laboratoire d’Analyse de Systemes Repartis

Ouverts et tres Disponibles

Le laboratoire d’analyse de systemes repartis ouverts et tres disponibles (ou DORSALpour l’anglais Distributed open reliable systems analysis lab) a ete cree en 2009 a l’initia-tive de Robert Roy et Michel Dagenais, tous deux professeurs au departement GIGLa l’EPM.

Les activites de recherche du laboratoire sont orientees sur l’amelioration de la per-formance, de la fiabilite et de la resilience des systemes distribues et multi-cœurs. Lesresultats des recherches effectuees au DORSAL sont rendus disponibles pour tous par lebiais de logiciels libres pour Linux et autres plateformes. Le laboratoire dispose d’environ400 000 CAD par an comme budget de recherche.

Etant tres proche de l’industrie, le laboratoire compte parmi ses partenaires des en-treprises telles qu’Ericsson, Google, Recherche et developpement pour la defense Canada,IBM, Red Hat, Novell, Debian et la Fondation Eclipse.

Le projet LTTng presente au chapitre 2, est, par exemple, issu des travaux de re-cherches menes au laboratoire. Le laboratoire a aussi contribue a des ameliorations dunoyau de Linux qui font aujourd’hui partie de la distribution officielle de ce dernier. Enfin,plusieurs logiciels developpes au DORSAL ont ete integres aux distributions SuSE Linux,Ubuntu et Debian.

Les travaux realises au laboratoire, sous la direction des professeurs Michel Dagenais,Robert Roy et Francois Bertrand sont egalement publies dans plusieurs conferences etjournaux scientifiques.

6

Chapitre 2

Linux Trace Toolkit next generation(LTTng)

2.1 Qu’est-ce que le tracage ?

2.1.1 Allegorie de la « boıte noire »Dans un avion, la boıte noire sert a enregistrer, entre autres, les donnees des capteurs,

les discussions du cockpit et les commandes executees par les pilotes afin de pouvoir, lecas echeant, juger des bonnes decisions prises par le personnel naviguant et de leur bonneanalyse des donnees qui leur sont disponibles. Ainsi, on pourra par exemple savoir, encas de crash, si c’est une erreur humaine ou un probleme materiel qui en a ete la causepremiere.

Le tracage informatique a, d’une certaine facon, le meme but. Lorsqu’un programmes’execute et plante, il est utile de savoir ce qu’il s’est passe : est-ce que l’erreur vientdu programme lui-meme, ou du systeme sur lequel il s’execute ? Est-ce que cette erreurest due au materiel ou au logiciel ? Tracer son execution prend alors tout son sens etpermettra, par exemple, d’analyser par etape l’execution d’un programme et du systemequi l’entoure. C’est la raison pour laquelle on peut assimiler le tracage a une boıte noirepour ordinateur.

2.1.2 Definition

Le tracage est une technique utilisee pour comprendre ce qui se passe dans un systemeafin de le deboguer ou de le surveiller. Un traceur est le logiciel utilise pour le tracage.Le tracage peut etre utilise pour deboguer un large eventail de bugs qui sont par ailleursextremement difficile a identifier. Il s’agit, par exemple, des problemes de performancedans les systemes paralleles complexes ou les systemes temps reel.

Le tracage est similaire a la journalisation (ou logging) : ca consiste a enregistrer lesevenements qui se produisent dans un systeme. Cependant, par rapport a la journalisation,on enregistre des evenements de beaucoup plus bas niveau qui se produisent de maniereplus frequente. Les traceurs doivent donc etre optimises pour gerer un grand nombre dedonnees tout en ayant un faible impact sur le systeme. Les traces produisent generalementdes milliers d’evenements par seconde. Elles contiennent des millions d’evenements et ont

7

CHAPITRE 2. LINUX TRACE TOOLKIT NEXT GENERATION (LTTNG)

des tailles de plusieurs mega-octets a plusieurs dizaines de gigaoctets.Des traces peuvent inclure des evenements du noyau du systeme d’exploitation (ges-

tionnaire d’Interrupt Request (IRQ) en entree / sortie, appels systemes en entree / sortie,activite d’ordonnancement, activite du reseau, etc.) Ils peuvent egalement comprendre desevenements provoques par des applications.

On pourrait lire directement la liste des evenements d’une trace, a la maniere d’unfichier journal, ce qui nous donnerait de ce fait le niveau maximum de details. Cependant,des analyseurs et des visualisateurs de traces sont disponibles, et permettent de produiredes graphiques et des statistiques a propos de cette enorme quantite de donnees. Ces pro-grammes doivent etre specialement concus pour traiter rapidement les grosses quantitesde donnees que les traces contiennent.

2.2 Un premier ensemble d’outils : Linux Trace Tool-

kit (LTT)

En 1999, plusieurs outils etaient deja disponibles pour analyser les systemes d’infor-mation, et bien qu’une partie d’entre eux fut deja repandue, l’information qu’ils rappor-taient etait jugee insuffisante ou incomplete : les outils bases sur l’echantillonnage nerapportaient qu’une estimation du comportement du systeme tandis que ceux bases surl’instrumentation avaient souvent un surcout eleve. Malgre des variations sur les modesd’echantillonnage et les techniques d’instrumentation qui ont permis d’augmenter la fia-bilite de ces outils tout en en reduisant le surcout, ils demeuraient incapables de restituerla dynamique du systeme dans son ensemble.

Il etait alors interessant de trouver un moyen de fournir un ensemble d’outils capablesde presenter a leurs utilisateurs une reconstruction fidele du comportement dynamiquedu systeme, ainsi que des mesures exactes sur sa performance. L’utilisateur serait alors enmesure d’identifier les surcouts dus aux conflits de partage des ressources, mais aussi d’envisualiser les causes. Par exemple, les temps d’attente causes par un acces au disque etceux causes par un partage du processeur avec d’autres processus seraient differentiables.

Karim Yaghmour a donc consacre ses recherches de maıtrise au developpement del’ensemble d’outils Linux Trace Toolkit (LTT), qui accumulait ses donnees par moyend’instrumentation du noyau [36]. Cette instrumentation consistait a enregistrer les eve-nements importants du noyau dans un tampon a des fins d’analyse. Un ensemble demodules logiciels etait utilise pour permettre cette fonctionnalite, et un outil d’analyse(dont la visualisation de graphe des evenements est montree sur la figure 2.2) permet-tait a l’utilisateur d’analyser les donnees accumulees et d’en extraire les informationspertinentes.

LTT permettait de reconstruire efficacement le comportement du systeme tout en li-mitant le surcout a moins de 2.5 % lors de l’observation des evenements noyaux basiques.De plus, la disponibilite de son code source, en tant que logiciel libre, lui conferait l’avan-tage de pouvoir evoluer et etendre ses fonctionnalites (autant au niveau des evenementsenregistres qu’au niveau du traitement des donnees accumulees).

8


Figure 2.1 – Graphique des evenements dans LTT 0.9.5

9


2.3 La nouvelle generation

Figure 2.2 – Logo du logiciel LTTng

En 2005, le projet LTT n’etant, depuis quelques temps deja, plus maintenu, Ma-thieu Desnoyers devient l’auteur du projet Linux Trace Toolkit next generation

(LTTng) ayant pour but de remplacer LTT tout en conservant sa base d’utilisateurs,d’ou son nom. Si les points d’instrumentation utilises par LTT sont repris dans LTTng, ils’agit d’un systeme bien different. Il definira les objectifs premiers du projet dans sa thesecomme etant le fait [11] :

– de repondre aux attentes dans le domaine du tracage de l’industrie et de la com-munaute du logiciel libre ;

– de creer un traceur pour Linux – comme l’etait LTT, Linux etant un systeme d’ex-ploitation largement utilise ;

– de developper chaque composant du traceur afin que leur combinaison conserve lesproprietes de mise a l’echelle et n’ait qu’un faible impact sur le debit et la latencemoyenne du systeme d’exploitation ;

– de garantir un impact temps reel deterministe du tracage ;– d’obtenir des mecanismes de tracage ayant une portabilite et une reentrance accrues.

Cette partie sera principalement consacree au survol du fonctionnement de LTTng,le but d’un traceur ayant deja ete evoque en 2.1. La version 0.x est jusqu’a present laversion stable de LTTng, tandis que la 2.0 est en developpement.

2.3.1 Version 0.x

LTTng 0.x fut le debut du projet LTTng. Cette version est toujours supportee maisn’est plus developpee, au profit de la version 2.0.

Pour utiliser cette version, il est necessaire d’appliquer un patchset au noyau qui, entreautres, y ajoutera l’horloge de tracage specifique a LTTng, modifiera certains points detrace et en ajoutera d’autres. Ce patchset permet ensuite d’utiliser les differents elementscomposant le systeme :

Le traceur est gere en tant que tel par des modules du noyau Linux qui se chargent delire les informations au niveau de points de trace et de les stocker en memoire ;

Le consommateur (ou consumer) est gere par un demon du systeme (de l’anglaisdaemon) qui se charge de recuperer les donnees stockees en memoire par le traceur

10


Figure 2.3 – Capture d’ecran de la visualisation d’une trace avec LTTV [33] ; differentescouleurs correspondent a differents etats deduits des evenements.

Figure 2.4 – Capture d’ecran de la visualisation d’une trace avec le plugin Eclipse [17] ;Differentes couleurs correspondent a differents etats deduits des evenements.

11


et de les ecrire sur le disque dur par l’intervention d’un ring buffer (ou tamponcirculaire) ;

LTTctl qui permet a l’utilisateur de controler le demon ;

LTTV qui est l’outil de visualisation des traces generees, autant en mode console (tui)qu’en mode graphique (gui), visible sur la figure 2.3.1. Une bibliotheque de LTTV

permet de visualiser les traces dans Eclipse via un plugin, un apercu est donne surla figure 2.3.1 ;

UserSpace Tracer (UST) 0.x ou traceur espace utilisateur, il est concu pour fournirdes informations detaillees sur l’activite en espace utilisateur. Des points d’instru-mentation UST peuvent etre ajoutes dans tout code de l’espace utilisateur, y comprisles gestionnaires de signaux et les bibliotheques. Le format d’enregistrement destraces utilise par UST et son horloge etant les memes que ceux du traceur noyau,LTTV peut les fusionner afin de les visualiser ensemble.

2.3.2 Version 2.0

En 2010, Mathieu Desnoyers et la Multicore Association 1 mettent au point unformat de trace standardise : le Common Trace Format (CTF).

Figure 2.5 – Capture d’ecran de la visualisation d’une trace avec lttngtop ; cet outilpermet aussi de revivre pas a pas ce qu’il s’est passe lors de la capture de la trace, pourainsi pouvoir identifier un probleme plus facilement.

1. La Multicore Association, fondee en 2005, est un consortium industriel a but non lucratif et financepar ses membres. Elle est axee sur la creation de d’API standards ouverts, de specifications et de directivesqui permettront aux developpeurs systeme et aux programmeurs d’adopter des technologies multicœursdans leurs applications plus facilement.

12


Ce nouveau format de trace, et le desir de centraliser le controle du tracage poussenta la creation d’une nouvelle version de LTTng qui sera une reecriture de la precedente :LTTng 2.0. Voici une liste non-exhaustive des changements apportes par rapport a LTTng

0.x et de ce qui les a motives :

Le CTF et babeltrace, son outil de visualisation : CTF est le format d’enregistre-ment des traces officiel de LTTng 2.0. Ces standards, distribues sous des licencesdu type BSD, pourraient donc etre utilises par tous les utilisateurs (autant dansl’industrie que dans le domaine libre) pour generer des traces, ce qui ouvre la pos-sibilite, dans l’avenir, d’utiliser les memes outils pour deboguer des problemes tantmateriels que logiciels, tout en permettant la lecture des traces, toutes correlees viahorodatage (ou timestamp) dans le meme outil.

Le demon sessiond : le demon sessiond permet de centraliser la gestion des tracesde l’espace utilisateur (via UST) et noyau en permettant aux applications UST des’authentifier directement aupres de lui. De plus, sessiond contient le registre dessessions de tracage et s’assure, lors de la demande de la realisation d’une trace, quele noyau et les applications enregistrees sont configures pour produire l’informationde trace demandee. Il permet de realiser toute la synchronisation d’installation entreles applications, le noyau et le consommateur. Enfin, il gere les droits d’acces, etpeut par exemple autoriser certains utilisateurs non-administrateurs a effectuer destraces noyau.

Une ligne d’interface commune pour le noyau et l’espace utilisateur : tout passemaintenant par sessiond pour configurer une operation de tracage. On passe doncpar la meme commande pour activer les points de trace UST et noyau avant delancer le tracage. A noter qu’il est tout a fait possible d’activer des points de tracedes deux types.

L’absence de patch noyau : la modularisation du noyau Linux a permis, puisque LTTngetait reecrit, de choisir une autre approche de l’ajout de nouveaux points de traceen se passant du patchset applique au noyau pour LTTng 0.x. Cette approche per-met a LTTng d’etre integre plus facilement dans les differentes distributions Linux,et d’etre installe plus aisement par un utilisateur lambda. Cependant, le fait de sepasser du patch noyau a provoque la perte de certaines fonctionnalites (certainspoints de trace encore impossibles a ajouter de facon modulaire).

lttngtop : qui est un nouvel outil, ou plus exactement une interface ncurses 2 pour lireet naviguer dans les traces enregistrees par LTTng 2.0, ainsi qu’afficher diversesstatistiques. Une capture d’ecran de cette interface est visible dans la figure 2.3.2.lttngtop tient son nom de la commande top, permettant de visualiser en directl’etat des processus du systeme.

2.3.3 Cas pratique : enregistrer en seulement quelques minutesune trace avec LTTng

Configurer le systeme pour prendre une trace avec LTTng est tres simple, le plus longetant de selectionner les informations voulues et de ne pas s’encombrer de celles inutiles

2. ncurses, de new curses, est une bibliotheque libre fournissant une API pour le developpementd’environnements en mode texte.

13


quand on sait precisement ce que l’on souhaite surveiller. Afin de mieux comprendrecomment ca fonctionne, cette partie presentera etape par etape la creation d’une traceavec LTTng jusqu’a sa visualisation avec lttngtop ou babeltrace.

2.3.3.1 Creation d’une session de tracage

La premiere etape est bien evidemment de creer une session de tracage. La commandeest la suivante :

root@ utt# lttng create UTT -o /home/xaf/utt -lttng -20120127

Session UTT created.

Traces will be written in /home/xaf/utt -lttng -20120127

Dans ce cas, nous avons cree la session « UTT » pour laquelle les traces seront enre-gistrees dans le dossier « /home/xaf/utt-lttng-20110127 ». Le fait de preciser le dossiern’est pas obligatoire, et dans le cas ou on l’omettrait, un dossier par defaut serait defini.

Pour avoir plus d’informations sur une commande en particulier, une option d’aide estdisponible pour chacune des commandes de LTTng, elle peut etre appelee comme suit :

root@ utt# lttng create --help

usage: lttng create [options] [NAME]

-h, --help Show this help

-o, --output PATH Specify output path for traces

2.3.3.2 Activer des evenements a surveiller

Maintenant que notre session de tracage « UTT » est creee, il faut lui preciser queltype d’evenement elle devra surveiller. Si l’on souhaite definir avec precision quels evene-ments on souhaite surveiller, il faudra effectuer la commande suivante pour chacun desevenements en question :

root@ utt# lttng enable -event -[type] [ evenement]

Ou bien sur on remplacera « -[type] » par -u ou -k selon que l’on souhaite surveillerun evenement UST respectivement noyau (kernel). Et « [evenement] » sera substitue parl’un des evenements disponibles pour le type choisi, dont on pourra connaıtre la liste al’aide de la commande suivante :

root@ utt# lttng list -[type]

Puisqu’ici il s’agit de creer une trace en quelques minutes, et que nous n’avons pasbesoin d’evenements particuliers, considerons que nous souhaitons ajouter tous les eve-nements du noyau :

root@ utt# lttng enable -event -k -a

All kernel events are enabled in channel channel0

2.3.3.3 Definir un contexte

Definir le contexte, c’est a dire les valeurs que l’on souhaite recuperer pour chaqueevenement enregistre, n’est pas obligatoire. Auquel cas, toutes les valeurs seront enregis-trees. Dans le cas ou l’on souhaite visualiser precisement certaines choses, par exempledans lttngtop, il peut etre utile de le definir. Dans notre cas, definissons par exemple lecontexte suivant :

14


root@ utt# lttng add -context -k -t pid -t prio -t ppid -t perf:major -faults -t perf:

branch -misses -t perf:cache -misses

kernel context perf:cache -misses added to all event in all channels

kernel context perf:branch -misses added to all event in all channels

kernel context perf:major -faults added to all event in all channels

kernel context ppid added to all event in all channels

kernel context prio added to all event in all channels

kernel context pid added to all event in all channels

On identifie au -k que l’on a ajoute ces contextes pour le tracage du noyau (le retourle confirme). Ici, on a donc demande a avoir comme information de contexte pid, soitl’identifiant du processus, prio, soit la priorite du processus, ppid, soit l’identifiant duprocessus parent, ainsi que trois compteurs d’erreurs, prefixes par perf:.

2.3.3.4 Demarrer le tracage

Une fois notre session de tracage correctement configuree, il nous reste simplement ala demarrer :

root@ utt# lttng start

Tracing started for session UTT

A partir de maintenant, tous les evenements correspondants a ceux que nous avonsactives seront enregistres dans la trace.

2.3.3.5 Arreter le tracage

Une fois toutes les operations a tracer enregistrees, il est inutile de continuer de fairegrossir la trace, nous pouvons donc l’arreter :

root@ utt# lttng stop

Tracing stopped for session UTT

Ou la detruire directement, si nous n’avons pas besoin de la reutiliser :

root@ utt# lttng destroy

Session UTT destroyed at /root

En effet, la commande destroy se chargera automatiquement de stopper la session sielle ne l’est pas, et la detruira afin qu’on ne puisse y ajouter des donnees par inadvertance.La session sera detruite, mais les traces conservees.

La commande stop, quant a elle, permet d’arreter provisoirement le tracage, parexemple lorsque ce n’est plus pertinent de tracer et de faire grossir le fichier de logs, puisde le reprendre plus tard en utilisant a nouveau la commande start.

2.3.3.6 Visualiser la trace

babeltrace comme lttngtop permettent tous deux de visualiser la trace, mais dedeux manieres differentes. Tandis que babeltrace fournit un environnement textuel danslequel on peut lire ligne par ligne la suite d’evenements, a la maniere d’un fichier dejournalisation, lttngtop permet de son cote une visualisation plus conviviale, tout enpermettant de voir l’evolution de l’execution pas a pas.

Pour executer babeltrace :

root@ utt# babeltrace /home/xaf/utt -20120127

15


Pour executer lttngtop :

root@ utt# lttngtop /home/xaf/utt -20120127

2.4 Les entreprises impliquees dans le developpement

De nombreuses entreprises travaillent avec le laboratoire DORSAL sur LTTng. Parmielles, on denote principalement Ericsson, qui travaille en lien etroit avec le laboratoireet s’occupe du developpement du plugin Eclipse, pour l’instant associe a LTTng 0.x,la Multicore Association, citee precedemment pour le developpement du CTF, DefenceResearch and Development Canada (DRDC), et plus globalement tous les contributeursdu projet de recherche Distributed Multi-Core Tracing (DMCT) dont LTTng fait partie.

16

Chapitre 3

Projet de recherche

Dans les premiers temps de mon arrivee au laboratoire DORSAL, mon travail futd’etudier les travaux en cours, les travaux deja realises, et surtout d’apprendre a utiliseret comprendre le fonctionnement des outils utilises et developpes par le laboratoire, telsLTTng (presente au chapitre 2).

Une fois que j’eus mieux compris la demarche entreprise par le laboratoire et le fonc-tionnement ainsi que le but de ses outils open source, il etait necessaire de definir un sujetde recherche sur lequel m’orienter, tenant compte a la fois de ma formation a l’UTT, demes interets de recherche et de ceux du laboratoire. On m’a alors propose un projet financepar le CRIAQ 1, dont le but etait la portabilite temps reel du logiciel LTTng afin d’etreutilise par des entreprises comme CAE 2 – dans leurs simulateurs pour l’aeronautique –ou Opal-RT Technologies 3 – dans leurs systemes temps reel embarques.

Joignant a la fois ma formation Ingenieur de l’UTT et mes interets pour l’informatiqueet l’aerospatiale, ce projet correspondait parfaitement a mes attentes. Cette partie a pourbut de retracer mon travail de recherche des six derniers mois : je commencerai par definirle concept d’un systeme temps reel avant de presenter les differentes etapes de l’evolutionde ma recherche.

3.1 Un systeme temps reel

Pour definir de maniere simple un systeme temps reel, on peut prendre l’image d’undrone se dirigeant a toute vitesse sur une falaise. Le systeme embarque de ce drone doittout d’abord acquerir les conditions environnementales a l’aide de capteurs, les traiter puiseffectuer une action en consequence. Ici, il devra donc identifier la presence de la falaise,en deduire qu’il doit devier de son trajet et calculer l’angle de son virage, puis restituer

1. Le CRIAQ, ou Consortium de recherche et d’innovation en aerospatiale au Quebec, est un consor-tium a but non lucratif qui a ete forme dans le but de promouvoir et de realiser des projets de rechercheindustrielle au stade pre concurrentiel principalement dans les universites [10]. http://www.criaq.aero

2. CAE est un leader mondial dans le domaine des technologies de simulation et de modelisationet des solutions integrees de formation destinees a l’aviation civile et aux forces de defense du mondeentier [18]. http://www.cae.com/

3. Fonde en 1997, Opal-RT Technologies est un des chefs de file des entreprises internationales sespecialisant dans l’ingenierie en temps reel. L’entreprise fabrique et vend une technologie unique, quireduit les delais de conception et de mise en place de systemes temps reel complexe [4]. http://www.opal-rt.com/

17

http://www.criaq.aero

http://www.cae.com/

http://www.opal-rt.com/

http://www.opal-rt.com/

CHAPITRE 3. PROJET DE RECHERCHE

ces donnees calculees et commander la robotique physique pour effectuer le virage. Bienevidemment, toutes ces etapes doivent etre realisees avant que le drone n’atteigne lafalaise : c’est le principe d’un systeme temps reel. Un systeme temps reel fonctionneradonc selon trois etapes telles que representees sur la figure 3.1, c’est a dire l’acquisition,le traitement, et enfin la restitution et la commande.

Acquisition TraitementRestitution et Commande

Système « temps réel »

Environnement

Figure 3.1 – Representation des etapes de fonctionnement d’un systeme temps reel

En suivant toujours le meme modele, on comprend aisement que l’information obtenueen restitution n’est valable que si la commande a le temps d’etre executee, autrement ditsi notre drone a le temps, une fois qu’il a pris la decision d’effectuer un virage et qu’ila calcule son angle, de l’executer avant d’atteindre la falaise. C’est la qu’entre en jeu lanotion de limite temporelle : le fait de devoir faire un virage, et l’angle de ce virage serontpeut-etre calcules correctement d’apres les donnees acquises au depart, mais si le calculn’a pas ete effectue dans un delai raisonnable durant lequel le drone a encore le temps del’executer, le resultat ne pourra etre considere comme juste.

On prendra pour definition d’un tel systeme la suivante : « Un systeme temps reel estun systeme dans lequel l’exactitude des calculs ne depend pas seulement de l’exactitudelogique du calcul, mais aussi de l’heure a laquelle le resultat est produit. Si les contraintestemporelles du systeme ne sont pas remplies, le systeme sera considere comme defaillant. »

En d’autres termes, le systeme doit etre deterministe pour garantir que la reponsesera donne dans les temps face a des charges variables (de la plus faible charge a la pluselevee). Le determinisme requis le sera sur deux criteres :

– le determinisme logique, c’est a dire que les memes donnees acquises par le systemedoivent produire la meme restitution et l’execution des memes commandes ;

– le determinisme temporel, c’est a dire qu’une tache donnee doit obligatoirement etreexecutee dans les delais impartis, on parle alors d’echeance.

Et l’on pourra diviser les systemes temps reel en deux categories selon le cote plusstrict ou souple des contraintes a remplir par le systeme :

– Les systemes temps reel a contraintes souples (de l’anglais Soft Real Time (SRT))pour lesquels les evenements traites trop tardivement ou perdus sont sans conse-quence catastrophique pour la bonne marche du systeme. On peut citer l’exemple

18


des systemes multimedia (notamment le streaming video) pour lesquels si l’on perdquelques images, le fonctionnement de l’ensemble du systeme n’est pas mis en peril ;

– Les systemes temps reel a contraintes strictes (ou temps reel dur, de l’anglais HardReal Time (HRT)) qui correspondent a des systemes d’exploitations pouvant re-pondre a des sollicitations ou evenements (internes ou externes) dans un tempsmaximum (determinisme temporel fort). On peut citer comme exemples les sys-temes de regulation des centrales nucleaires ou les systemes embarques utilises enaeronautique.

Fort de ces informations, on pourra classifier aisement le systeme pris pour exempleau debut de cette section comme un systeme a contraintes strictes. Dans le cas de cesysteme, il sera bien sur necessaire d’avoir une latence optimale, condition d’un systemetemps reel, mais aussi de bonnes performances et rapidites de traitement compte tenu dela rapidite de vol du drone.

Cependant, ces performances et rapidites de traitement ne sont pas du tout carac-teristiques d’un systeme temps reel ! Pour l’expliquer, definissons un deuxieme systemetemps reel : un robot aspirateur. Ce robot avancera a une vitesse basse et ne pourrase deplacer qu’au ras du sol. Si ce robot s’approche d’un mur, il est necessaire que sonsysteme embarque traite cette information et change de direction, mais il disposera deplus de temps pour le faire etant donne qu’il s’approchera beaucoup moins vite du mur.Pourtant, il s’agit toujours d’un systeme temps reel : les calculs pour le changement de di-rection doivent etre effectues avant que le robot n’ait plus le temps de mettre a executionla commande correspondante, sinon il atteindra le mur et pourra subir des dommages,il a donc une echeance de reaction. Nous sommes par consequent toujours dans le casd’un systeme temps reel a contraintes strictes, mais les performances et la rapidite decomputation necessaires sont moindres par rapport au cas du drone. Les capteurs d’ac-quisition et les processeurs de traitement n’auront pas besoin d’etre aussi performants,mais la latence, elle, sera toujours importante, car le systeme devra respecter l’echeance.

On remarquera que la definition donnee precedemment ne parle en aucun cas de perfor-mance ou de vitesse de reponse car le temps reel n’a rien a voir avec ces caracteristiques :le temps reel concerne la predictabilite.

3.2 Les systemes d’exploitation temps reel

Une fois mon projet de recherche en main, la premiere etape etait d’effectuer un etatde l’art des systemes d’exploitation orientes temps reel, et d’ainsi avoir une vision plusglobale de ce qui etait necessaire sur le projet, et de ce qui pouvait etre mis en place.Durant cet etat de l’art, j’ai principalement etudie deux types d’architecture temps reel :l’approche micro-noyau et l’approche utilisee aujourd’hui nativement dans le noyau Linux.Cette partie a pour but de presenter ces deux architectures afin d’en faire un parallele.

3.2.1 Approche micro-noyau (ou thin-kernel)

Les premieres recherches ont mene vers des solutions de RTOS par extension tellesque RTLinux, RTAI (pour Real-Time Application Interface) et Xenomai [30, 28, 35].

19


Ces systemes, dont l’architecture est representee sur la figure 3.2, sont bases sur l’ajoutd’un second noyau comme couche d’abstraction entre le noyau linux et le materiel (ouhardware). Le noyau Linux s’execute en tache de fond du micro-noyau en tant que tachede plus faible priorite et accueille toutes les taches non-temps reel. Les taches temps reelsont executees directement sur le micro-noyau.

Couche matérielle (Hardware)

Micro-noyau (Thin-kernel)

Tâches temps réel

Noyau Linux(Non-temps réel)

Espace utilisateur (User-space)(Tâches non-temps réel)

Figure 3.2 – Approche micro-noyau pour le temps reel a contraintes strictes

Le micro-noyau a pour but principal (en plus d’accueillir les taches temps reel) degerer les interruptions. Il intercepte ainsi les interruptions pour s’assurer que le noyau non-temps reel ne puisse preempter le fonctionnement du micro-noyau, et ainsi interrompreune tache temps reel pour en executer une non-temps reel. C’est ce fonctionnement quipermet au micro-noyau de fournir un support du temps reel avec contraintes strictes.

Bien que l’approche du micro-noyau ait des avantages tels que le support du tempsreel a contraintes strictes coexistant avec un noyau Linux standard, cette approche a desinconvenients. Les taches temps reel et non-temps reel etant independantes, le debogageest rendu plus difficile. De plus, la communication entre les taches temps reel et des tachesde l’interface utilisateur ne sera rendue possible que par des FIFOs ou de la memoirepartagee.

3.2.2 Approche du temps reel dans le noyau standard Linux

Si l’approche presentee precedemment est interessante du point de vue architectural, ilreste qu’elle opere autour du noyau. Etant donne le but de mes recherches, autrement ditla portabilite d’un logiciel travaillant directement sur le noyau Linux pour fonctionner surdes systemes temps reel, l’interet serait que le noyau standard Linux incorpore directementles changements necessaires pour supporter le temps reel.

20


Si l’on utilise le noyau standard (c’est a dire sans configuration specifique), lorsqu’unprocessus de l’espace utilisateur fait un appel systeme (system call), il ne peut pas etrepreempte. Ca signifie que si un processus de basse priorite effectue un appel systeme, unprocessus de haute priorite devra attendre que le precedent se termine avant de pouvoirutiliser le processeur. Heureusement, depuis le noyau 2.6, l’option CONFIG PREEMPT

de la configuration rend possible un autre comportement du noyau en permettant auxprocessus d’etre preemptes si une tache de haute priorite apparaıt (et ce meme si leprocessus est au milieu d’un appel systeme). On aura ainsi un noyau preemptible obtenantles performances requises par un systeme temps reel a contraintes souples. La figure 3.3presente l’architecture d’un tel noyau avec la preemption activee.

Couche matérielle (Hardware)

Espace utilisateur(User-space)

Processus temps réel

Processusnon-temps réel

Tâche temps réel

Tâchenon-temps réel

Noyau Linux(avec préemption)

Figure 3.3 – Approche du noyau standard de linux avec preemption

Cependant, cette configuration a une contrepartie. Bien qu’elle permette d’atteindredes performances d’un systeme temps reel a contraintes souples et de faire fonctionner lesysteme d’exploitation normalement meme sous de fortes charges, le debit et les perfor-mances du noyau sont legerement reduits en raison de la surcharge ajoutee de l’optionCONFIG PREEMPT. Ainsi, cette option sera utile pour un ordinateur de bureau (oudesktop) ou un systeme embarque mais ne sera pas adaptee pour tous les scenarios (parexemple dans le cas d’un serveur).

Sur ce type de noyau, des performances temps reel a contraintes strictes sont tout a faitenvisageables, mais il faut pour cela appliquer un patch specifique, appele PREEMPT RT.Ce patch a pour effet de donner au noyau Linux un comportement temps reel dur tout enlimitant le nombre de modifications apportees. Les changements apportes par ce patchpermettent de rendre preemptible la majeure partie du noyau en reimplementant certainesdes primitives de verrouillage de celui-ci, en convertissant les gestionnaires d’interruptionsen fils d’execution (ou thread) du noyau afin qu’ils soient pleinement preemptables, et enmettant en œuvre l’heritage de priorite pour les mutex internes au noyau afin de proteger

21


du probleme connu sous le nom d’« inversion de priorite 4. »Certaines fonctionnalites developpees pour ce patch par Ingo Molnar 5 ont depuis

ete integrees au noyau standard.

J’ai choisi de m’orienter sur une approche temps reel basee sur une configurationnoyau de ce type pour y poursuivre mes recherches.

3.3 Contraintes materielles et logicielles

Lorsque je me suis installe au laboratoire, on m’a confie un ordinateur, que j’appelleraiici station A, dont la configuration materielle est la suivante :

Carte mere Supermicro X7DAL

Processeur Deux Intel® Xeon® E5405, fournissant chacun quatre cœurs de processeurcadences a 2.00GHz

Memoire Systeme Quatre KINGSTON® DIMM DDR2 Synchrone 667 MHz de 2GBchaque.

Une distribution Debian testing (soit wheezy/sid au moment de l’ecriture de ce rap-port) fonctionnant sur un noyau Linux 3.0 avec le patch PREEMPT RT a ete installee surcette station, me permettant d’y effectuer tous les tests necessaires a mon nouveau but :trouver une solution permettant de determiner si un systeme est apte a faire du tempsreel.

3.3.1 Un systeme inapte au temps reel

Ayant une bonne idee de la definition d’un systeme temps reel et ayant choisi mon ar-chitecture et installe un systeme en consequence, mes recherches m’ont tres vite orienteesvers la suite « rt-tests » maintenue par Clark Williams. Cette suite est un groupementde programmes qui permettent de tester et de mesurer des composantes variables ducomportement d’un noyau temps reel.

3.3.1.1 Les premiers tests : cyclictest

Je me suis tres vite oriente sur des tests avec cyclictest, un programme de test dela haute resolution des horloges systeme.

En effectuant plusieurs milliers de tests par seconde, tests consistants en une boucleet un calcul de la duree de cette boucle, cyclictest permet de tester la latence et le

4. L’inversion de priorite est un probleme qui peut se rencontrer en programmation concurrente, ilest rencontre lorsqu’un processus de haute priorite ne peut acceder au processeur car un processus deplus faible priorite l’utilise deja. Par exemple, si une tache de faible priorite F est preemptee apres avoirobtenu un verrou V , et que la tache de plus haute priorite H ayant cause la preemption de F necessited’obtenir le meme verrou V : ce verrou ayant ete acquis par F , il ne sera pas disponible pour H, et latache de haute priorite n’aura pas acces a la ressource processeur concernee tandis qu’une tache de plusfaible priorite y aura acces.

5. Ingo Molnar est un « kernel hacker » d’origine hongroise travaillant pour la societe Red Hat.

22


fonctionnement des minuteurs haute resolution (high resolution timers) d’un systeme enmicrosecondes (µs). cyclictest permet de visualiser en direct ses calculs de latencesur le systeme, en affichant pour chaque thread de test en cours d’execution toutes sesinformations :

– T : numero du processeur sur lequel le thread est execute ; entre parentheses, lenumero du processus de ce thread ;

– P : priorite du processus ;– I : intervalle entre deux cycles ;– C : nombre de cycles deja realises ;– Min : latence minimum sur l’ensemble des cycles realises (en µs) ;– Act : latence actuelle (en µs) ; c’est a dire pour le cycle en cours ;– Avg : latence moyenne sur l’ensemble des cycles realises (en µs) ;– Max : latence maximum sur l’ensemble des cycles realises (en µs).

J’ai choisi d’executer la commande ./cyclictest -S -p95 pour tester mon systeme,c’est a dire que l’on fait un test Symmetric MultiProcessing (SMP) standard en utili-sant tous les processeurs, en executant un thread par processeur, en utilisant l’horlogeclock nanosleep (option -S) et que l’on definit pour chacun de ces thread une priorite de95, 99 etant le maximum (option -p95).

Lors de l’execution, le premier retour, presente dans la figure 3.4, nous montre que lethread s’executant sur le huitieme processeur presente deja une latence de plus de 1600 µs.C’est sans surprise que moins de deux secondes plus tard, les valeurs etaient beaucoupplus elevees, de l’ordre de 18 ms (voir figure 3.5).

1 # /dev/cpu_dma_latency set to 0us

2 policy: fifo: loadavg: 0.15 0.20 0.21 1/658 15249

34 T: 0 (15242) P:95 I:1000 C: 93 Min: 2 Act: 4 Avg: 3 Max: 7








Figure 3.4 – Retour d’execution de cyclictest sur la station A : immediatement apresle debut du test, le huitieme thread depasse la barre des 1 ms de latence

Seulement quelques secondes apres, ces pics de latence atteignaient les 38 ms. Laquestion etait maintenant de savoir s’il s’agissait d’un probleme materiel ou logiciel.

Pour repondre a cette question, un premier essai a consiste en l’installation d’unedistribution de Linux sur un disque dur USB afin de s’assurer que ma configurationpersonnelle du systeme n’interferait pas avec les tests. Le resultat etait le meme sur cetordinateur, tandis que d’autres obtenaient de tres bons resultats en utilisant le memedisque dur USB. Il semblait donc que le probleme n’etait pas logiciel.

23












Figure 3.5 – Retour d’execution de cyclictest sur la station A : un peu plus d’uneseconde apres le debut du test, le pallier des 19 ms de latence est deja atteint

3.3.1.2 Des tests materiels : hwlatdetect

L’outil hwlatdetect, present dans la suite rt-tests, m’offrait un test alternatif enverifiant directement la latence engendree par le systeme. Cet outil se base sur un moduledu noyau Linux, hwlat_detector, qui permet d’effectuer les tests directement dans lenoyau selon des parametres donnes au module lorsqu’on l’importe. Malheureusement, maversion du noyau Linux, la 3.0, etait trop recente pour pouvoir y ajouter cette version dumodule, la 1.0.0, limitee aux noyaux 2.6. Ces tests devant etre effectues, j’ai donc entreprisd’apporter les modifications adequates au module afin qu’il puisse fonctionner sur unnoyau 3.0. Apres de nombreux tatonnements, et une fois les problemes de compatibiliteidentifies, j’ai pu creer un patch permettant d’utiliser cette nouvelle version du module,hwlat_detector 1.1.0 (disponible en annexe B).

Une fois le module pret, il fut installe sur la station A pour y effectuer les tests delatence materielle. Les resultats furent mauvais mais en accord avec ceux du cyclictest

comme on peut le voir sur la figure 3.6 : 38 ms de latence, qui etaient donc provoques parle materiel. De plus, si on se penche sur le rapport contenant les enregistrements depassantla latence exigee (disponible en annexe A.1), on remarque que ceux-ci correspondent bienaux deux etapes pallier de cyclictest (19 ms et 38 ms).

1 root@rt-tests# ./ hwlatdetect --threshold =1 --report =/my/output

23 hwlatdetect: test duration 120 seconds

4 parameters:

5 Latency threshold: 1us

67 Sample window: 1000000 us

8 Sample width: 500000 us

9 Non -sampling period: 500000 us

10 Output File: /my/output

11 Starting test

12 test finished

13 Max Latency: 38136us

14 Samples recorded: 45

15 Samples exceeding threshold: 45

16 sample data written to /my/output

Figure 3.6 – Resultat de hwlatdetect sur la station A : la latence maximum materielleatteint les 38 ms, ce qui est enorme mais correspond aux resultats du cyclictest

Les tests effectues par le module hwlat_detector permettent de detecter les System

24


Management Interrupt (SMI). Les SMIs sont des interruptions installees par le BIOS quisont utilisees pour gerer differents elements tels que la gestion de la batterie, la protectioncontre la surchauffe (overheat protection) ainsi que l’emulation de certains peripheriques(tels que IDE, PS/2, etc.). Apres etre alle dans la configuration du BIOS dans le butde desactiver toutes ces fonctionnalites, hwlatdetect retournait toujours de mauvaisresultats. Les resultats des tests ne depassaient plus les 19 ms, ce qui etait deja beaucouptrop eleve pour le but recherche.

3.3.2 Un nouveau systeme plus adapte

Fort des conclusions de la partie precedente, et aide dans ma decision par des avisdonnes sur la liste officielle des utilisateurs de Linux temps reel, linux-rt-users [14], je suispasse sur un autre ordinateur, que j’appellerai ici station B, qui dispose des caracteris-tiques physiques suivantes :

Carte mere Intel Corporation DX58SO

Processeur Un Intel® Core� i7 920, fournissant quatre cœurs de processeur cadencesa 2.67GHz

Memoire Systeme Trois KINGSTON® DIMM DDR3 Synchrone 1067 MHz de 2GBchaque.

Le systeme d’exploitation « portable » sur disque dur USB sera le seul utilise pour lestests a partir de la, me permettant de tester mes resultats sur de multiples architecturessi besoin. Il s’agit aussi d’une distribution Debian testing avec un noyau 3.0 patche avecPREEMPT RT et hwlat_detector.

Des les premiers essais sur la station B, qui m’avait a l’origine servi de comparaisonavec la station A, les tests se sont averes concluants comme on peut le voir dans lesfigures 3.7 et 3.8.



34 T: 0 ( 3660) P:95 I:1000 C: 27045 Min: 2 Act: 3 Avg: 3 Max: 20




Figure 3.7 – Retour d’execution de cyclictest sur la station B : apres plus de 10 000cycles par processus la latence maximum dans les cycles n’a pas depasse 20 µs

Cette station nous permet, de plus, de demarquer clairement la latence provoquee parle materiel (2 µs) de celle atteinte par le logiciel (de 6 µs a 20 µs).

3.4 Implementation d’un outil de test de non-preemption

d’un processus de la plus haute priorite

L’etape actuelle de mes recherches concerne le developpement d’un nouvel outil per-mettant de tester les performances temps reel d’un systeme d’un autre point de vue.

25


1 root@rt-tests# ./ hwlatdetect --threshold =1 --report =/my/output

23 hwlatdetect: test duration 120 seconds

4 parameters:

5 Latency threshold: 1us

6 Sample window: 1000000 us

7 Sample width: 500000 us

8 Non -sampling period: 500000 us

9 Output File: /my/output

1011 Starting test

12 test finished

13 Max Latency: 2us

14 Samples recorded: 5

15 Samples exceeding threshold: 5

1617 sample data written to /my/output

Figure 3.8 – Resultat de hwlatdetect sur la station B : la latence maximum rencontreependant la periode de test du materiel ne depasse pas les 2 µs

Autrement dit, il s’agit ici de verifier si un processus execute avec la plus haute prioritepossible sur un processeur bien defini peut finir par etre interrompu, meme une nanose-conde.

Cet outil a son importance puisqu’avant de pouvoir tester le tracage d’une applicationtemps reel, il est important de mesurer a quel point cela impacte sur ses performancestemps reel. Les outils utilises pour mes premiers tests etaient certes utiles, mais l’aspectde la preemption d’une tache de haute priorite n’etait pas traite.

L’idee de ce programme vient de l’entreprise Opal-RT Technologies, avec laquelle jefais les tests et evolutions du programme. A ce stade de la recherche, deux etapes sontnecessaires a l’execution du programme : mettre en place un shield CPU ou bouclier pro-cesseur et activer/desactiver les bonnes options dans le noyau de maniere dynamique (voirannexe C), puis executer un programme dont le but est de faire travailler le processeursans relache.

3.4.1 Le « shield CPU »Dans un systeme multiprocesseurs, un « processeur protege » (ou shielded CPU ) est

un processeur dedie aux activites associees aux taches de haute priorite temps reel. Mar-quer un processeur comme protege permet aux ressources de ce processeur d’etre reserveesa ces taches de haute priorite. De plus, l’environnement d’execution d’un processeur pro-tege favorise le determinisme necessaire pour le support des applications temps reel. End’autres mots, un processeur protege permet de garantir de rapides reponses aux inter-ruptions exterieures et de fournir un environnement plus deterministe pour executer destaches temps reel.

Passer par un systeme de processeur protege nous permet donc theoriquement, en plusde notre systeme installe de maniere a supporter le temps reel a contraintes strictes, derenforcer les capacites temps reel du systeme pour le ou les processeurs qui seront placesderriere le bouclier.

De plus, le but de notre programme de test etant de faire travailler un processeursans relache, proteger l’execution sur ce processeur est tout a fait sense puisqu’il s’agit

26


de s’assurer que le temps d’execution de notre processus ne sera pas partage sur plu-sieurs processeurs afin de ne pas ajouter de latence au changement de processeur, et den’identifier ainsi que des latences dues a des interruptions materielles.

La mise en place d’un bouclier processeurs sous Linux passe par l’utilisation descgroup. Un cgroup permet de gerer les processus par groupes afin de mieux les controler,et via l’utilisation du controleur cpuset du cgroup, on pourra choisir d’isoler un pro-cesseur, de la memoire, mais aussi de desactiver la balance de charge par exemple. Pardefaut, un processus n’etant pas dans un cgroup aura acces a toutes les ressources quin’ont pas ete allouees.

Par exemple, isolons un processeur dans un cgroup. Il faut tout d’abord montercgroup, puis creer un repertoire que nous appellerons « test ». test sera donc notrepremier cgroup.

root@shield# mkdir /cgroupsroot@shield# mount -t cgroup -ocpuset cpuset /cgroupsroot@shield# mkdir /cgroups/test

Maintenant que notre cgroup test est cree, appliquons-lui les contraintes necessairesa son isolation.

root@shield# echo 0 > /cgroups/test/cpuset.cpusroot@shield# echo 0 > /cgroups/test/cpuset.memsroot@shield# echo 0 > /cgroups/test/cpuset.sched_load_balanceroot@shield# echo 1 > /cgroups/test/cpuset.cpu_exclusive

Si maintenant l’on veut executer un programme dans ce groupe, apres avoir deplacele processus de notre terminal dans le cgroup correspondant (echo $$ > /cgroups/test

/tasks en root), il ne pourra acceder qu’au processeur 0.Pour que cette modification soit pertinente, il est interessant de deplacer aussi les

IRQs vers un autre processeur que le courant. On choisira par exemple le processeur 2(CPU1) si l’on utilise, comme ici, le premier (CPU0).

root@shield# for i in /proc/irq /[0 -9]*; do> echo 2 > $i/smp_affinity 2>/dev/null>done

Ainsi, notre processeur protege dans le groupe test ne devrait plus etre importune parles IRQs, et le programme devrait pouvoir etre execute sans s’arreter.

3.4.2 Programme d’analyse du respect de la non-preemptiondes processus de haute-priorite temps reel

Le programme execute effectue une boucle pour un nombre de cycles tres eleve (de-termine a l’avance et passe en ligne de commande) et calcule, a chaque tour, combien de

27


temps il a mis pour le parcourir. Tenant compte du fait que le processeur est isole, il nedevrait y avoir aucun probleme pour faire tourner le programme sans avoir de delai.

A des fins d’analyse, un histogramme est genere, permettant de faire statistiques surle nombre de pics et leurs niveaux (en µs). Cet histogramme n’est ecrit sur le disque qu’ala fin de l’execution du programme, pour ne pas alterer les resultats.

Apres 5 000 000 000 de cycles, voici l’histogramme obtenu :

1 microsecondes;nombre de cycles;2 0;4999999998;3 322;1;4 528;1;

On remarque que si la majorite des cycles ont ete executes en moins d’une microse-conde (la valeur moyenne retournee par le programme est de 107 ns), il y a deux picsbeaucoup plus eleves. C’est ici que l’intervention d’un traceur est utile : qu’est-ce quiprovoque ces pics de latence et pourquoi, alors que notre processeur est isole, nous lesavons ? Implementer un traceur pourrait repondre a cette question en nous permettantd’analyser ce qui se passe au niveau du noyau en parallele des cycles du programme.

LTTng permet de faire ce suivi, mais il faut pour ca instrumenter le programme avecUST afin qu’il ait ses propres points de trace et permette de lancer et arreter une tracede maniere autonome (un humain ne reagira jamais aussi vite que le programme lui-meme). Si ce travail est actuellement en cours, la principale difficulte rencontree est lefait qu’ajouter un systeme de tracage ajoute de la latence, et en regardant l’histogrammeobtenu en executant le programme tandis qu’un systeme de tracage est actif au niveaudu noyau, on peut voir que les pics precedemment identifies ne sont plus aussi faciles areperer : quelle est la part du traceur dans ces nouvelles latences ?

1 microsecondes;nombre de cycles;2 0;4999999742;3 1;3;4 2;2;5 3;8;6 4;196;7 5;25;8 6;1;9 7;1;

10 18;4;11 19;6;12 20;2;13 25;1;14 120;1;15 122;1;16 130;1;17 157;1;18 208;1;19 358;1;20 387;1;21 435;1;

28


LTTng 2.0 devrait implementer d’ici peu une nouvelle horloge qui pourrait regler leprobleme et permettre de realiser ce tracage tout en ayant une idee du moment ou lespics sont survenus.

29

Conclusion

Durant ces six mois dans le laboratoire DORSAL, j’ai eu l’occasion d’evoluer au seind’une equipe de recherche travaillant sur divers projets autour d’une meme base. J’ai pumettre a l’epreuve mes competences et en developper de nouvelles dans le domaine de larecherche, domaine que je n’avais jusqu’a present pas eu l’occasion d’approcher.

Le sujet de recherche qui m’a ete confie, totalement en accord avec mes interets per-sonnels et professionnels, a ete jusqu’a present tres formateur. Mon travail consistait enl’etude des systemes temps reel et des moyens de les identifier afin d’aider a ameliorer lesoutils du logiciel LTTng. Pour repondre a ces attentes, il a ete necessaire que je comprenneles notions de tracage, que j’apprenne a utiliser le logiciel developpe par le laboratoire, etenfin que je fasse une revue de litterature sur les systemes temps reel et les notions memessur lesquelles sont bases ces systemes. Une fois apte a tenir des discussions techniques surces sujets, j’ai pu rencontrer et devenir le contact ressource de l’un des partenaires duprojet auquel je m’etais greffe, Opal-RT, pour travailler en collaboration avec lui sur unoutil d’analyse de performances temps reel.

L’objectif final de mon projet, autrement dit la participation au developpement d’ou-tils de trace d’execution pour des systemes embarques et mobiles multicœurs sous linux,a ete atteint puisque les recherches que j’ai menees jusqu’a present et le developpementde l’outil d’analyse seront utiles a l’amelioration de l’outil de tracage. Je pense par conse-quent avoir demontre ma capacite d’adaptation a un domaine d’activite – la recherche –encore inconnu et prouve mes competences dans un environnement multiculturel.

Mon objectif personnel vis a vis de ce projet a lui aussi ete atteint. J’ai pu decouvrirla recherche scientifique en genie tout en renforcant mes connaissances et en en acquerantde nouvelles dans le domaine des technologies mobiles et des systemes embarques. J’ai desle debut pu prendre des initiatives, et me suis tres vite senti a l’aise grace a la confianceque l’on m’accordait sur la maniere de traiter mon sujet.

Ma formation a l’UTT et mes experiences passees ont ete exploitees durant ces sixmois, ou j’ai pu par exemple mettre en parallele le contexte international du fait de vivredans un autre pays avec le mineur Culture Internationale et Entreprise (CIE) et monexperience professionnelle passee a la Food and Agriculture Organization of the UnitedNations (FAO of the UN). J’ai, de meme, pu mettre a profit tout au long de mon projetde fin d’etudes mes facultes a percevoir des problematiques complexes et a rechercherl’information, telles que la formation d’ingenieur le requiert.

30

CONCLUSION

Le domaine de la recherche est tres interessant est varie, autant par les gens que l’onpeut rencontrer que par l’approche du travail en laboratoire, qui est tres differente d’untravail de bureau dans l’industrie. Les contraintes ne sont pas les memes, et bien qu’ausein du laboratoire DORSAL les realisations soient generalement concretes, le travail aavant tout un but de recherche et il arrive souvent d’etre confronte a l’echec et de devoirtrouver une solution alternative. Cette experience m’a permis de decouvrir cet environ-nement et d’apprendre a y evoluer, tout en faisant des rencontres de personnes avec quije ne doute pas garder contact par la suite.

L’accueil dans le laboratoire de la part de l’equipe a ete tres chaleureux, me per-mettant de me sentir a l’aise des le premier jour, mais outre l’aspect humain, je penseavoir acquis d’un point de vue professionnel plus de rigueur dans mes recherches et unemeilleure facon d’organiser mon travail dans ce but.

Enfin, rejoindre le laboratoire DORSAL m’a permis de me mettre dans la peau d’unchercheur en genie informatique et d’etre soumis aux memes problematiques et question-nements. Je peux donc affirmer, desormais, que je comprends bien mieux les implicationsdu metier de la recherche. Cette experience me sera, sans nul doute, benefique pour lasuite de ma carriere professionnelle.

31

Table des annexes

A. Enregistrements realises par hwlatdetect . . . . . . . . . . . . 33

A.1 Sur la station A . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

A.2 Sur la station B . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

B. Patch noyau pour le module hwlat detector 1.1.0 . . . . . . 35

C. Configuration dynamique du noyau via sysctl . . . . . . . . . 55

D. Organisation de la recherche durant les 24 semaines de projet 56

E. Curriculum Vitae . . . . . . . . . . . . . . . . . . . . . . . . . . 57

32

Annexe A

Enregistrements realises parhwlatdetect

A.1 Sur la station A

1 1319575592.0802426354 190612 1319575593.0806426299 23 1319575608.0898425572 190654 1319575610.0906425467 190635 1319575616.0930425175 26 1319575620.0950424982 190487 1319575622.0958424885 28 1319575627.0010424686 29 1319575629.0026424590 19063

10 1319575630.0030424546 1904811 1319575633.0046424390 1906312 1319575634.0050424344 1903713 1319575637.0062424197 3812514 1319575641.0078423997 1908215 1319575642.0082423947 1906216 1319575649.0110423608 1906617 1319575650.0114423561 1905018 1319575651.0118423511 1904819 1319575655.0138423311 220 1319575659.0154423121 1906921 1319575661.0162423015 1907222 1319575662.0166422975 1904923 1319575664.0174422870 1906824 1319575665.0178422825 1906325 1319575666.0182422774 1905926 1319575668.0190422679 1905527 1319575670.0198422577 1905128 1319575671.0202422531 1906029 1319575674.0222422384 230 1319575676.0230422288 3810631 1319575680.0246422092 3813632 1319575682.0254421988 1904533 1319575683.0258421943 1904534 1319575685.0266421842 1905835 1319575689.0282421645 2

33

ANNEXE A. ENREGISTREMENTS REALISES PAR HWLATDETECT

36 1319575695.0318421354 237 1319575696.0322421303 1905038 1319575697.0326421258 1908539 1319575699.0342421159 1904940 1319575701.0366421057 1903941 1319575702.0386420994 1904942 1319575704.0390420911 1906543 1319575706.0398420818 1905344 1319575707.0402420761 1903645 1319575710.0446420605 2

A.2 Sur la station B

1 1327379500.0998975278 22 1327379523.0086975776 23 1327379526.0098975850 24 1327379540.0154976166 25 1327379559.0230976596 2

34

Annexe B

Patch noyau pour le modulehwlat detector 1.1.0

1 hwlat_detector: A system hardware latency detector

23 This patch introduces a new hardware latency detector module that can be used

4 to detect high hardware -induced latencies within the system. It was originally

5 written for use in the RT kernel , but has wider applications.

6 Original -by: Jon Masters <[email protected] >

78 Signed -off -by: Raphael Beamonte <[email protected] >

910 Index: xaf/Documentation/hwlat_detector.txt

11 ============ =======================================================

12 --- /dev/null

13 +++ xaf/Documentation/hwlat_detector.txt

14 @@ -0,0 +1,64 @@

15 +Introduction:

16 +-------------

17 +

18 +The module hwlat_detector is a special purpose kernel module that is used to

19 +detect large system latencies induced by the behavior of certain underlying

20 +hardware or firmware , independent of Linux itself. The code was developed

21 +originally to detect SMIs (System Management Interrupts) on x86 systems ,

22 +however there is nothing x86 specific about this patchset. It was

23 +originally written for use by the "RT" patch since the Real Time

24 +kernel is highly latency sensitive.

25 +

26 +SMIs are usually not serviced by the Linux kernel , which typically does not

27 +even know that they are occuring. SMIs are instead are set up by BIOS code

28 +and are serviced by BIOS code , usually for "critical" events such as

29 +management of thermal sensors and fans. Sometimes though , SMIs are used for

30 +other tasks and those tasks can spend an inordinate amount of time in the

31 +handler (sometimes measured in milliseconds). Obviously this is a problem if

32 +you are trying to keep event service latencies down in the microsecond range.

33 +

34 +The hardware latency detector works by hogging all of the cpus for configurable

35 +amounts of time (by calling stop_machine ()), polling the CPU Time Stamp Counter

36 +for some period , then looking for gaps in the TSC data. Any gap indicates a

37 +time when the polling was interrupted and since the machine is stopped and

38 +interrupts turned off the only thing that could do that would be an SMI.

39 +

40 +Note that the SMI detector should *NEVER* be used in a production environment.

41 +It is intended to be run manually to determine if the hardware platform has a

42 +problem with long system firmware service routines.

43 +

44 +Usage:

45 +------

46 +

47 +Loading the module hwlat_detector passing the parameter "enabled =1" (or by

35

ANNEXE B. PATCH NOYAU POUR LE MODULE HWLAT DETECTOR 1.1.0

48 +setting the "enable" entry in "hwlat_detector" debugfs toggled on) is the only

49 +step required to start the hwlat_detector. It is possible to redefine the

50 +threshold in microseconds (us) above which latency spikes will be taken

51 +into account (parameter "threshold =").

52 +

53 +Example:

54 +

55 + # modprobe hwlat_detector enabled =1 threshold =100

56 +

57 +After the module is loaded , it creates a directory named "hwlat_detector" under

58 +the debugfs mountpoint , "/debug/hwlat_detector" for this text. It is necessary

59 +to have debugfs mounted , which might be on /sys/debug on your system.

60 +

61 +The /debug/hwlat_detector interface contains the following files:

62 +

63 +count - number of latency spikes observed since last reset

64 +enable - a global enable/disable toggle (0/1), resets count

65 +max - maximum hardware latency actually observed (usecs)

66 +sample - a pipe from which to read current raw sample data

67 + in the format <timestamp > <latency observed usecs >

68 + (can be opened O_NONBLOCK for a single sample)

69 +threshold - minimum latency value to be considered (usecs)

70 +width - time period to sample with CPUs held (usecs)

71 + must be less than the total window size (enforced)

72 +window - total period of sampling , width being inside (usecs)

73 +

74 +By default we will set width to 500 ,000 and window to 1,000,000, meaning that

75 +we will sample every 1,000,000 usecs (1s) for 500 ,000 usecs (0.5s). If we

76 +observe any latencies that exceed the threshold (initially 100 usecs),

77 +then we write to a global sample ring buffer of 8K samples , which is

78 +consumed by reading from the "sample" (pipe) debugfs file interface.

79 Index: xaf/drivers/misc/Kconfig

80 ============ =======================================================

81 --- xaf.orig/drivers/misc/Kconfig

82 +++ xaf/drivers/misc/Kconfig

83 @@ -76,6 +76,34 @@ config IBM_ASM

84 information on the specific driver level and support statement

85 for your IBM server.

8687 +config HWLAT_DETECTOR

88 + tristate "Testing module to detect hardware -induced latencies"

89 + depends on DEBUG_FS

90 + default m

91 + ---help ---

92 + A simple hardware latency detector. Use this module to detect

93 + large latencies introduced by the behavior of the underlying

94 + system firmware external to Linux. We do this using periodic

95 + use of stop_machine to grab all available CPUs and measure

96 + for unexplainable gaps in the CPU timestamp counter(s). By

97 + default , the module is not enabled until the "enable" file

98 + within the "hwlat_detector" debugfs directory is toggled.

99 +

100 + This module is often used to detect SMI (System Management

101 + Interrupts) on x86 systems , though is not x86 specific. To

102 + this end , we default to using a sample window of 1 second ,

103 + during which we will sample for 0.5 seconds. If an SMI or

104 + similar event occurs during that time , it is recorded

105 + into an 8K samples global ring buffer until retreived.

106 +

107 + WARNING: This software should never be enabled (it can be built

108 + but should not be turned on after it is loaded) in a production

109 + environment where high latencies are a concern since the

110 + sampling mechanism actually introduces latencies for

111 + regular tasks while the CPU(s) are being held.

112 +

113 + If unsure , say N

114 +

115 config PHANTOM

116 tristate "Sensable PHANToM (PCI)"

117 depends on PCI

36


118 Index: xaf/drivers/misc/Makefile

119 ============ =======================================================

120 --- xaf_quilt.orig/drivers/misc/Makefile

121 +++ xaf_quilt/drivers/misc/Makefile

122 @@ -38,6 +38,7 @@

123 obj -$(CONFIG_HMC6352) += hmc6352.o

124 obj -y += eeprom/

125 obj -y += cb710/

126 +obj -$(CONFIG_HWLAT_DETECTOR) += hwlat_detector.o

127 obj -$(CONFIG_SPEAR13XX_PCIE_GADGET) += spear13xx_pcie_gadget.o

128 obj -$(CONFIG_VMWARE_BALLOON) += vmw_balloon.o

129 obj -$(CONFIG_ARM_CHARLCD) += arm -charlcd.o

130 Index: xaf_quilt/drivers/misc/hwlat_detector.c

131 ============ =======================================================

132 --- /dev/null

133 +++ xaf/drivers/misc/hwlat_detector.c

134 @@ -0,0 +1 ,1212 @@

135 +/*

136 + * hwlat_detector.c - A simple Hardware Latency detector.

137 + *

138 + * Use this module to detect large system latencies induced by the behavior of

139 + * certain underlying system hardware or firmware , independent of Linux itself.

140 + * The code was developed originally to detect the presence of SMIs on Intel

141 + * and AMD systems , although there is no dependency upon x86 herein.

142 + *

143 + * The classical example usage of this module is in detecting the presence of

144 + * SMIs or System Management Interrupts on Intel and AMD systems. An SMI is a

145 + * somewhat special form of hardware interrupt spawned from earlier CPU debug

146 + * modes in which the (BIOS/EFI/etc.) firmware arranges for the South Bridge

147 + * LPC (or other device) to generate a special interrupt under certain

148 + * circumstances , for example , upon expiration of a special SMI timer device ,

149 + * due to certain external thermal readings , on certain I/O address accesses ,

150 + * and other situations. An SMI hits a special CPU pin , triggers a special

151 + * SMI mode (complete with special memory map), and the OS is unaware.

152 + *

153 + * Although certain hardware -inducing latencies are necessary (for example ,

154 + * a modern system often requires an SMI handler for correct thermal control

155 + * and remote management) they can wreak havoc upon any OS-level performance

156 + * guarantees toward low -latency , especially when the OS is not even made

157 + * aware of the presence of these interrupts. For this reason , we need a

158 + * somewhat brute force mechanism to detect these interrupts. In this case ,

159 + * we do it by hogging all of the CPU(s) for configurable timer intervals ,

160 + * sampling the built -in CPU timer , looking for discontiguous readings.

161 + *

162 + * WARNING: This implementation necessarily introduces latencies. Therefore ,

163 + * you should NEVER use this module in a production environment

164 + * requiring any kind of low -latency performance guarantee(s).

165 + *

166 + * Copyright (C) 2008 -2009 Jon Masters , Red Hat , Inc. <[email protected] >

167 + * 1.1.0 edited in 2011 by Raphael Beamonte <[email protected] >

168 + *

169 + * Includes useful feedback from Clark Williams <[email protected] >

170 + *

171 + * This file is licensed under the terms of the GNU General Public

172 + * License version 2. This program is licensed "as is" without any

173 + * warranty of any kind , whether express or implied.

174 + */

175 +

176 +#include <linux/module.h>

177 +#include <linux/init.h>

178 +#include <linux/ring_buffer.h>

179 +#include <linux/stop_machine.h>

180 +#include <linux/time.h>

181 +#include <linux/hrtimer.h>

182 +#include <linux/kthread.h>

183 +#include <linux/debugfs.h>

184 +#include <linux/seq_file.h>

185 +#include <linux/uaccess.h>

186 +#include <linux/version.h>

187 +#include <linux/slab.h>

37


188 +#include <linux/delay.h>

189 +

190 +#define BUF_SIZE_DEFAULT 262144 UL /* 8K*( sizeof(entry)) */

191 +#define BUF_FLAGS (RB_FL_OVERWRITE) /* no block on full */

192 +#define U64STR_SIZE 22 /* 20 digits max */

193 +

194 +#define VERSION "1.1.0"

195 +#define BANNER "hwlat_detector: "

196 +#define DRVNAME "hwlat_detector"

197 +#define DEFAULT_SAMPLE_WINDOW 1000000 /* 1s */

198 +#define DEFAULT_SAMPLE_WIDTH 500000 /* 0.5s */

199 +#define DEFAULT_LAT_THRESHOLD 10 /* 10us */

200 +

201 +/* Module metadata */

202 +

203 +MODULE_LICENSE ("GPL");

204 +MODULE_AUTHOR ("Jon Masters <[email protected] >");

205 +MODULE_DESCRIPTION ("A simple hardware latency detector ");

206 +MODULE_VERSION(VERSION);

207 +

208 +/* Module parameters */

209 +

210 +static int debug;

211 +static int enabled;

212 +static int threshold;

213 +

214 +module_param(debug , int , 0); /* enable debug */

215 +module_param(enabled , int , 0); /* enable detector */

216 +module_param(threshold , int , 0); /* latency threshold */

217 +

218 +/* Buffering and sampling */

219 +

220 +static struct ring_buffer *ring_buffer; /* sample buffer */

221 +static DEFINE_MUTEX(ring_buffer_mutex); /* lock changes */

222 +static unsigned long buf_size = BUF_SIZE_DEFAULT;

223 +static struct task_struct *kthread; /* sampling thread */

224 +

225 +/* DebugFS filesystem entries */

226 +

227 +static struct dentry *debug_dir; /* debugfs directory */

228 +static struct dentry *debug_max; /* maximum TSC delta */

229 +static struct dentry *debug_count; /* total detect count */

230 +static struct dentry *debug_sample_width; /* sample width us */

231 +static struct dentry *debug_sample_window; /* sample window us */

232 +static struct dentry *debug_sample; /* raw samples us */

233 +static struct dentry *debug_threshold; /* threshold us */

234 +static struct dentry *debug_enable; /* enable/disable */

235 +

236 +/* Individual samples and global state */

237 +

238 +struct sample; /* latency sample */

239 +struct data; /* Global state */

240 +

241 +/* Sampling functions */

242 +static int __buffer_add_sample(struct sample *sample);

243 +static struct sample *buffer_get_sample(struct sample *sample);

244 +static int get_sample(void *unused);

245 +

246 +/* Threading and state */

247 +static int kthread_fn(void *unused);

248 +static int start_kthread(void);

249 +static int stop_kthread(void);

250 +static void __reset_stats(void);

251 +static int init_stats(void);

252 +

253 +/* Debugfs interface */

254 +static ssize_t simple_data_read(struct file *filp , char __user *ubuf ,

255 + size_t cnt , loff_t *ppos , const u64 *entry);

256 +static ssize_t simple_data_write(struct file *filp , const char __user *ubuf ,

257 + size_t cnt , loff_t *ppos , u64 *entry);

38


258 +static int debug_sample_fopen(struct inode *inode , struct file *filp);

259 +static ssize_t debug_sample_fread(struct file *filp , char __user *ubuf ,

260 + size_t cnt , loff_t *ppos);

261 +static int debug_sample_release(struct inode *inode , struct file *filp);

262 +static int debug_enable_fopen(struct inode *inode , struct file *filp);

263 +static ssize_t debug_enable_fread(struct file *filp , char __user *ubuf ,

264 + size_t cnt , loff_t *ppos);

265 +static ssize_t debug_enable_fwrite(struct file *file ,

266 + const char __user *user_buffer ,

267 + size_t user_size , loff_t *offset);

268 +

269 +/* Initialization functions */

270 +static int init_debugfs(void);

271 +static void free_debugfs(void);

272 +static int detector_init(void);

273 +static void detector_exit(void);

274 +

275 +/* Individual latency samples are stored here when detected and packed into

276 + * the ring_buffer circular buffer , where they are overwritten when

277 + * more than buf_size/sizeof(sample) samples are received. */

278 +struct sample {

279 + u64 seqnum; /* unique sequence */

280 + u64 duration; /* ktime delta */

281 + struct timespec timestamp; /* wall time */

282 +};

283 +

284 +/* keep the global state somewhere. Mostly used under stop_machine. */

285 +static struct data {

286 +

287 + struct mutex lock; /* protect changes */

288 +

289 + u64 count; /* total since reset */

290 + u64 max_sample; /* max hardware latency */

291 + u64 threshold; /* sample threshold level */

292 +

293 + u64 sample_window; /* total sampling window (on+off) */

294 + u64 sample_width; /* active sampling portion of window */

295 +

296 + atomic_t sample_open; /* whether the sample file is open */

297 +

298 + wait_queue_head_t wq; /* waitqeue for new sample values */

299 +

300 +} data;

301 +

302 +/**

303 + * __buffer_add_sample - add a new latency sample recording to the ring buffer

304 + * @sample: The new latency sample value

305 + *

306 + * This receives a new latency sample and records it in a global ring buffer.

307 + * No additional locking is used in this case - suited for stop_machine use.

308 + */

309 +static int __buffer_add_sample(struct sample *sample)

310 +{

311 + return ring_buffer_write(ring_buffer ,

312 + sizeof(struct sample), sample);

313 +}

314 +

315 +/**

316 + * buffer_get_sample - remove a hardware latency sample from the ring buffer

317 + * @sample: Pre -allocated storage for the sample

318 + *

319 + * This retrieves a hardware latency sample from the global circular buffer

320 + */

321 +static struct sample *buffer_get_sample(struct sample *sample)

322 +{

323 + struct ring_buffer_event *e = NULL;

324 + struct sample *s = NULL;

325 + unsigned int cpu = 0;

326 +

327 + if (! sample)

39


328 + return NULL;

329 +

330 + /* ring_buffers are per -cpu but we just want any value */

331 + /* so we’ll start with this cpu and try others if not */

332 + /* Steven is planning to add a generic mechanism */

333 + mutex_lock (& ring_buffer_mutex);

334 + preempt_disable ();

335 + e = ring_buffer_consume(ring_buffer , smp_processor_id (), NULL , NULL);

336 + if (!e) {

337 + for_each_online_cpu(cpu) {

338 + e = ring_buffer_consume(ring_buffer , cpu , NULL , NULL);

339 + if (e)

340 + break;

341 + }

342 + }

343 +

344 + if (e) {

345 + s = ring_buffer_event_data(e);

346 + memcpy(sample , s, sizeof(struct sample));

347 + } else

348 + sample = NULL;

349 + preempt_enable ();

350 + mutex_unlock (& ring_buffer_mutex);

351 +

352 + return sample;

353 +}

354 +

355 +/**

356 + * get_sample - sample the CPU TSC and look for likely hardware latencies

357 + * @unused: This is not used but is a part of the stop_machine API

358 + *

359 + * Used to repeatedly capture the CPU TSC (or similar), looking for potential

360 + * hardware -induced latency. Called under stop_machine , with data.lock held.

361 + */

362 +static int get_sample(void *unused)

363 +{

364 + ktime_t start , t1, t2;

365 + s64 diff , total = 0;

366 + u64 sample = 0;

367 + int ret = 1;

368 +

369 + start = ktime_get (); /* start timestamp */

370 +

371 + do {

372 +

373 + t1 = ktime_get (); /* we’ll look for a discontinuity */

374 + t2 = ktime_get ();

375 +

376 + total = ktime_to_us(ktime_sub(t2, start)); /* sample width */

377 + diff = ktime_to_us(ktime_sub(t2, t1)); /* current diff */

378 +

379 + /* This shouldn ’t happen */

380 + if (diff < 0) {

381 + printk(KERN_ERR BANNER "time running backwards\n");

382 + goto out;

383 + }

384 +

385 + if (diff > sample)

386 + sample = diff; /* only want highest value */

387 +

388 + } while (total <= data.sample_width);

389 +

390 + /* If we exceed the threshold value , we have found a hardware latency */

391 + if (sample > data.threshold) {

392 + struct sample s;

393 +

394 + data.count ++;

395 + s.seqnum = data.count;

396 + s.duration = sample;

397 + s.timestamp = CURRENT_TIME;

40


398 + __buffer_add_sample (&s);

399 +

400 + /* Keep a running maximum ever recorded hardware latency */

401 + if (sample > data.max_sample)

402 + data.max_sample = sample;

403 +

404 + wake_up (&data.wq); /* wake up reader(s) */

405 + }

406 +

407 + ret = 0;

408 +out:

409 + return ret;

410 +}

411 +

412 +/*

413 + * kthread_fn - The CPU time sampling/hardware latency detection kernel thread

414 + * @unused: A required part of the kthread API.

415 + *

416 + * Used to periodically sample the CPU TSC via a call to get_sample. We

417 + * use stop_machine , whith does (intentionally) introduce latency since we

418 + * need to ensure nothing else might be running (and thus pre -empting).

419 + * Obviously this should never be used in production environments.

420 + *

421 + * stop_machine will schedule us typically only on CPU0 which is fine for

422 + * almost every real -world hardware latency situation - but we might later

423 + * generalize this if we find there are any actualy systems with alternate

424 + * SMI delivery or other non CPU0 hardware latencies.

425 + */

426 +static int kthread_fn(void *unused)

427 +{

428 + int err = 0;

429 + u64 interval = 0;

430 +

431 + while (! kthread_should_stop ()) {

432 +

433 + mutex_lock (&data.lock);

434 +

435 + err = stop_machine(get_sample , unused , 0);

436 + if (err) {

437 + /* Houston , we have a problem */

438 + mutex_unlock (&data.lock);

439 + goto err_out;

440 + }

441 +

442 + interval = data.sample_window - data.sample_width;

443 + do_div(interval , USEC_PER_MSEC); /* modifies interval value */

444 +


446 +

447 + if (msleep_interruptible(interval))

448 + goto out;

449 + }

450 + goto out;

451 +err_out:

452 + printk(KERN_ERR BANNER "could not call stop_machine , disabling\n");

453 + enabled = 0;

454 +out:

455 + return err;

456 +

457 +}

458 +

459 +/**

460 + * start_kthread - Kick off the hardware latency sampling/detector kthread

461 + *

462 + * This starts a kernel thread that will sit and sample the CPU timestamp

463 + * counter (TSC or similar) and look for potential hardware latencies.

464 + */

465 +static int start_kthread(void)

466 +{

467 + kthread = kthread_run(kthread_fn , NULL ,

41


468 + DRVNAME);

469 + if (IS_ERR(kthread)) {

470 + printk(KERN_ERR BANNER "could not start sampling thread\n");

471 + enabled = 0;

472 + return -ENOMEM;

473 + }

474 +

475 + return 0;

476 +}

477 +

478 +/**

479 + * stop_kthread - Inform the hardware latency samping/detector kthread to stop

480 + *

481 + * This kicks the running hardware latency sampling/detector kernel thread and

482 + * tells it to stop sampling now. Use this on unload and at system shutdown.

483 + */

484 +static int stop_kthread(void)

485 +{

486 + int ret;

487 +

488 + ret = kthread_stop(kthread);

489 +

490 + return ret;

491 +}

492 +

493 +/**

494 + * __reset_stats - Reset statistics for the hardware latency detector

495 + *

496 + * We use data to store various statistics and global state. We call this

497 + * function in order to reset those when "enable" is toggled on or off , and

498 + * also at initialization. Should be called with data.lock held.

499 + */

500 +static void __reset_stats(void)

501 +{

502 + data.count = 0;

503 + data.max_sample = 0;

504 + ring_buffer_reset(ring_buffer); /* flush out old sample entries */

505 +}

506 +

507 +/**

508 + * init_stats - Setup global state statistics for the hardware latency detector

509 + *

510 + * We use data to store various statistics and global state. We also use

511 + * a global ring buffer (ring_buffer) to keep raw samples of detected hardware

512 + * induced system latencies. This function initializes these structures and

513 + * allocates the global ring buffer also.

514 + */

515 +static int init_stats(void)

516 +{

517 + int ret = -ENOMEM;

518 +

519 + mutex_init (&data.lock);

520 + init_waitqueue_head (&data.wq);

521 + atomic_set (&data.sample_open , 0);

522 +

523 + ring_buffer = ring_buffer_alloc(buf_size , BUF_FLAGS);

524 +

525 + if (WARN(! ring_buffer , KERN_ERR BANNER

526 + "failed to allocate ring buffer !\n"))

527 + goto out;

528 +

529 + __reset_stats ();

530 + data.threshold = DEFAULT_LAT_THRESHOLD; /* threshold us */

531 + data.sample_window = DEFAULT_SAMPLE_WINDOW; /* window us */

532 + data.sample_width = DEFAULT_SAMPLE_WIDTH; /* width us */

533 +

534 + ret = 0;

535 +

536 +out:

537 + return ret;

42


538 +

539 +}

540 +

541 +/*

542 + * simple_data_read - Wrapper read function for global state debugfs entries

543 + * @filp: The active open file structure for the debugfs "file"

544 + * @ubuf: The userspace provided buffer to read value into

545 + * @cnt: The maximum number of bytes to read

546 + * @ppos: The current "file" position

547 + * @entry: The entry to read from

548 + *

549 + * This function provides a generic read implementation for the global state

550 + * "data" structure debugfs filesystem entries. It would be nice to use

551 + * simple_attr_read directly , but we need to make sure that the data.lock

552 + * spinlock is held during the actual read (even though we likely won ’t ever

553 + * actually race here as the updater runs under a stop_machine context).

554 + */

555 +static ssize_t simple_data_read(struct file *filp , char __user *ubuf ,

556 + size_t cnt , loff_t *ppos , const u64 *entry)

557 +{

558 + char buf[U64STR_SIZE ];

559 + u64 val = 0;

560 + int len = 0;

561 +

562 + memset(buf , 0, sizeof(buf));

563 +

564 + if (!entry)

565 + return -EFAULT;

566 +


568 + val = *entry;


570 +

571 + len = snprintf(buf , sizeof(buf), "%llu\n", (unsigned long long)val);

572 +

573 + return simple_read_from_buffer(ubuf , cnt , ppos , buf , len);

574 +

575 +}

576 +

577 +/*

578 + * simple_data_write - Wrapper write function for global state debugfs entries


580 + * @ubuf: The userspace provided buffer to write value from

581 + * @cnt: The maximum number of bytes to write


583 + * @entry: The entry to write to

584 + *

585 + * This function provides a generic write implementation for the global state

586 + * "data" structure debugfs filesystem entries. It would be nice to use

587 + * simple_attr_write directly , but we need to make sure that the data.lock

588 + * spinlock is held during the actual write (even though we likely won ’t ever

589 + * actually race here as the updater runs under a stop_machine context).

590 + */

591 +static ssize_t simple_data_write(struct file *filp , const char __user *ubuf ,

592 + size_t cnt , loff_t *ppos , u64 *entry)

593 +{


595 + int csize = min(cnt , sizeof(buf));

596 + u64 val = 0;

597 + int err = 0;

598 +

599 + memset(buf , ’\0’, sizeof(buf));

600 + if (copy_from_user(buf , ubuf , csize))


602 +

603 + buf[U64STR_SIZE -1] = ’\0’; /* just in case */

604 + err = strict_strtoull(buf , 10, &val);

605 + if (err)

606 + return -EINVAL;

607 +

43



609 + *entry = val;


611 +

612 + return csize;

613 +}

614 +

615 +/**

616 + * debug_count_fopen - Open function for "count" debugfs entry

617 + * @inode: The in-kernel inode representation of the debugfs "file"


619 + *

620 + * This function provides an open implementation for the "count" debugfs

621 + * interface to the hardware latency detector.

622 + */

623 +static int debug_count_fopen(struct inode *inode , struct file *filp)

624 +{

625 + return 0;

626 +}

627 +

628 +/**

629 + * debug_count_fread - Read function for "count" debugfs entry





634 + *

635 + * This function provides a read implementation for the "count" debugfs

636 + * interface to the hardware latency detector. Can be used to read the

637 + * number of latency readings exceeding the configured threshold since

638 + * the detector was last reset (e.g. by writing a zero into "count").

639 + */

640 +static ssize_t debug_count_fread(struct file *filp , char __user *ubuf ,

641 + size_t cnt , loff_t *ppos)

642 +{

643 + return simple_data_read(filp , ubuf , cnt , ppos , &data.count);

644 +}

645 +

646 +/**

647 + * debug_count_fwrite - Write function for "count" debugfs entry


649 + * @ubuf: The user buffer that contains the value to write

650 + * @cnt: The maximum number of bytes to write to "file"

651 + * @ppos: The current position in the debugfs "file"

652 + *

653 + * This function provides a write implementation for the "count" debugfs

654 + * interface to the hardware latency detector. Can be used to write a

655 + * desired value , especially to zero the total count.

656 + */

657 +static ssize_t debug_count_fwrite(struct file *filp ,

658 + const char __user *ubuf ,

659 + size_t cnt ,

660 + loff_t *ppos)

661 +{

662 + return simple_data_write(filp , ubuf , cnt , ppos , &data.count);

663 +}

664 +

665 +/**

666 + * debug_enable_fopen - Dummy open function for "enable" debugfs interface



669 + *

670 + * This function provides an open implementation for the "enable" debugfs


672 + */

673 +static int debug_enable_fopen(struct inode *inode , struct file *filp)

674 +{

675 + return 0;

676 +}

677 +

44


678 +/**

679 + * debug_enable_fread - Read function for "enable" debugfs interface





684 + *

685 + * This function provides a read implementation for the "enable" debugfs

686 + * interface to the hardware latency detector. Can be used to determine

687 + * whether the detector is currently enabled ("0\n" or "1\n" returned).

688 + */

689 +static ssize_t debug_enable_fread(struct file *filp , char __user *ubuf ,


691 +{

692 + char buf [4];

693 +

694 + if ((cnt < sizeof(buf)) || (*ppos))

695 + return 0;

696 +

697 + buf[0] = enabled ? ’1’ : ’0’;

698 + buf[1] = ’\n’;

699 + buf[2] = ’\0’;

700 + if (copy_to_user(ubuf , buf , strlen(buf)))


702 + return *ppos = strlen(buf);

703 +}

704 +

705 +/**

706 + * debug_enable_fwrite - Write function for "enable" debugfs interface





711 + *

712 + * This function provides a write implementation for the "enable" debugfs

713 + * interface to the hardware latency detector. Can be used to enable or

714 + * disable the detector , which will have the side -effect of possibly

715 + * also resetting the global stats and kicking off the measuring

716 + * kthread (on an enable) or the converse (upon a disable).

717 + */

718 +static ssize_t debug_enable_fwrite(struct file *filp ,


720 + size_t cnt ,

721 + loff_t *ppos)

722 +{

723 + char buf [4];


725 + long val = 0;

726 + int err = 0;

727 +




731 +

732 + buf[sizeof(buf) -1] = ’\0’; /* just in case */

733 + err = strict_strtoul(buf , 10, &val);

734 + if (0 != err)


736 +

737 + if (val) {

738 + if (enabled)

739 + goto unlock;

740 + enabled = 1;

741 + __reset_stats ();

742 + if (start_kthread ())


744 + } else {

745 + if (! enabled)

746 + goto unlock;

747 + enabled = 0;

45


748 + stop_kthread ();

749 + wake_up (&data.wq); /* reader(s) should return */

750 + }

751 +unlock:

752 + return csize;

753 +}

754 +

755 +/**

756 + * debug_max_fopen - Open function for "max" debugfs entry



759 + *

760 + * This function provides an open implementation for the "max" debugfs


762 + */

763 +static int debug_max_fopen(struct inode *inode , struct file *filp)

764 +{

765 + return 0;

766 +}

767 +

768 +/**

769 + * debug_max_fread - Read function for "max" debugfs entry





774 + *

775 + * This function provides a read implementation for the "max" debugfs

776 + * interface to the hardware latency detector. Can be used to determine

777 + * the maximum latency value observed since it was last reset.

778 + */

779 +static ssize_t debug_max_fread(struct file *filp , char __user *ubuf ,


781 +{

782 + return simple_data_read(filp , ubuf , cnt , ppos , &data.max_sample);

783 +}

784 +

785 +/**

786 + * debug_max_fwrite - Write function for "max" debugfs entry





791 + *

792 + * This function provides a write implementation for the "max" debugfs

793 + * interface to the hardware latency detector. Can be used to reset the

794 + * maximum or set it to some other desired value - if, then , subsequent

795 + * measurements exceed this value , the maximum will be updated.

796 + */

797 +static ssize_t debug_max_fwrite(struct file *filp ,


799 + size_t cnt ,

800 + loff_t *ppos)

801 +{

802 + return simple_data_write(filp , ubuf , cnt , ppos , &data.max_sample);

803 +}

804 +

805 +

806 +/**

807 + * debug_sample_fopen - An open function for "sample" debugfs interface

808 + * @inode: The in-kernel inode representation of this debugfs "file"


810 + *

811 + * This function handles opening the "sample" file within the hardware

812 + * latency detector debugfs directory interface. This file is used to read

813 + * raw samples from the global ring_buffer and allows the user to see a

814 + * running latency history. Can be opened blocking or non -blocking ,

815 + * affecting whether it behaves as a buffer read pipe , or does not.

816 + * Implements simple locking to prevent multiple simultaneous use.

817 + */

46


818 +static int debug_sample_fopen(struct inode *inode , struct file *filp)

819 +{

820 + if (! atomic_add_unless (&data.sample_open , 1, 1))

821 + return -EBUSY;

822 + else

823 + return 0;

824 +}

825 +

826 +/**

827 + * debug_sample_fread - A read function for "sample" debugfs interface


829 + * @ubuf: The user buffer that will contain the samples read

830 + * @cnt: The maximum bytes to read from the debugfs "file"


832 + *

833 + * This function handles reading from the "sample" file within the hardware

834 + * latency detector debugfs directory interface. This file is used to read

835 + * raw samples from the global ring_buffer and allows the user to see a

836 + * running latency history. By default this will block pending a new

837 + * value written into the sample buffer , unless there are already a

838 + * number of value(s) waiting in the buffer , or the sample file was

839 + * previously opened in a non -blocking mode of operation.

840 + */

841 +static ssize_t debug_sample_fread(struct file *filp , char __user *ubuf ,


843 +{

844 + int len = 0;

845 + char buf [64];

846 + struct sample *sample = NULL;

847 +

848 + if (! enabled)

849 + return 0;

850 +

851 + sample = kzalloc(sizeof(struct sample), GFP_KERNEL);

852 + if (! sample)

853 + return -ENOMEM;

854 +

855 + while (! buffer_get_sample(sample)) {

856 +

857 + DEFINE_WAIT(wait);

858 +

859 + if (filp ->f_flags & O_NONBLOCK) {

860 + len = -EAGAIN;

861 + goto out;

862 + }

863 +

864 + prepare_to_wait (&data.wq, &wait , TASK_INTERRUPTIBLE);

865 + schedule ();

866 + finish_wait (&data.wq, &wait);

867 +

868 + if (signal_pending(current)) {

869 + len = -EINTR;

870 + goto out;

871 + }

872 +

873 + if (! enabled) { /* enable was toggled */

874 + len = 0;

875 + goto out;

876 + }

877 + }

878 +

879 + len = snprintf(buf , sizeof(buf), "%010lu.%010lu\t%llu\n",

880 + sample ->timestamp.tv_sec ,

881 + sample ->timestamp.tv_nsec ,

882 + sample ->duration);

883 +

884 +

885 + /* handling partial reads is more trouble than it’s worth */

886 + if (len > cnt)

887 + goto out;

47


888 +

889 + if (copy_to_user(ubuf , buf , len))

890 + len = -EFAULT;

891 +

892 +out:

893 + kfree(sample);

894 + return len;

895 +}

896 +

897 +/**

898 + * debug_sample_release - Release function for "sample" debugfs interface

899 + * @inode: The in-kernel inode represenation of the debugfs "file"


901 + *

902 + * This function completes the close of the debugfs interface "sample" file.

903 + * Frees the sample_open "lock" so that other users may open the interface.

904 + */

905 +static int debug_sample_release(struct inode *inode , struct file *filp)

906 +{

907 + atomic_dec (&data.sample_open);

908 +

909 + return 0;

910 +}

911 +

912 +/**

913 + * debug_threshold_fopen - Open function for "threshold" debugfs entry



916 + *

917 + * This function provides an open implementation for the "threshold" debugfs


919 + */

920 +static int debug_threshold_fopen(struct inode *inode , struct file *filp)

921 +{

922 + return 0;

923 +}

924 +

925 +/**

926 + * debug_threshold_fread - Read function for "threshold" debugfs entry





931 + *

932 + * This function provides a read implementation for the "threshold" debugfs

933 + * interface to the hardware latency detector. It can be used to determine

934 + * the current threshold level at which a latency will be recorded in the

935 + * global ring buffer , typically on the order of 10us.

936 + */

937 +static ssize_t debug_threshold_fread(struct file *filp , char __user *ubuf ,


939 +{

940 + return simple_data_read(filp , ubuf , cnt , ppos , &data.threshold);

941 +}

942 +

943 +/**

944 + * debug_threshold_fwrite - Write function for "threshold" debugfs entry





949 + *

950 + * This function provides a write implementation for the "threshold" debugfs

951 + * interface to the hardware latency detector. It can be used to configure

952 + * the threshold level at which any subsequently detected latencies will

953 + * be recorded into the global ring buffer.

954 + */

955 +static ssize_t debug_threshold_fwrite(struct file *filp ,


957 + size_t cnt ,

48


958 + loff_t *ppos)

959 +{

960 + int ret;

961 +

962 + ret = simple_data_write(filp , ubuf , cnt , ppos , &data.threshold);

963 +

964 + if (enabled)

965 + wake_up_process(kthread);

966 +

967 + return ret;

968 +}

969 +

970 +/**

971 + * debug_width_fopen - Open function for "width" debugfs entry



974 + *

975 + * This function provides an open implementation for the "width" debugfs


977 + */

978 +static int debug_width_fopen(struct inode *inode , struct file *filp)

979 +{

980 + return 0;

981 +}

982 +

983 +/**

984 + * debug_width_fread - Read function for "width" debugfs entry





989 + *

990 + * This function provides a read implementation for the "width" debugfs

991 + * interface to the hardware latency detector. It can be used to determine

992 + * for how many us of the total window us we will actively sample for any

993 + * hardware -induced latecy periods. Obviously , it is not possible to

994 + * sample constantly and have the system respond to a sample reader , or,

995 + * worse , without having the system appear to have gone out to lunch.

996 + */

997 +static ssize_t debug_width_fread(struct file *filp , char __user *ubuf ,


999 +{

1000 + return simple_data_read(filp , ubuf , cnt , ppos , &data.sample_width);

1001 +}

1002 +

1003 +/**

1004 + * debug_width_fwrite - Write function for "width" debugfs entry





1009 + *

1010 + * This function provides a write implementation for the "width" debugfs

1011 + * interface to the hardware latency detector. It can be used to configure

1012 + * for how many us of the total window us we will actively sample for any

1013 + * hardware -induced latency periods. Obviously , it is not possible to

1014 + * sample constantly and have the system respond to a sample reader , or,

1015 + * worse , without having the system appear to have gone out to lunch. It

1016 + * is enforced that width is less that the total window size.

1017 + */

1018 +static ssize_t debug_width_fwrite(struct file *filp ,


1020 + size_t cnt ,

1021 + loff_t *ppos)

1022 +{



1025 + u64 val = 0;

1026 + int err = 0;

1027 +

49





1031 +



1034 + if (0 != err)


1036 +


1038 + if (val < data.sample_window)

1039 + data.sample_width = val;

1040 + else {



1043 + }


1045 +

1046 + if (enabled)

1047 + wake_up_process(kthread);

1048 +

1049 + return csize;

1050 +}

1051 +

1052 +/**

1053 + * debug_window_fopen - Open function for "window" debugfs entry



1056 + *

1057 + * This function provides an open implementation for the "window" debugfs

1058 + * interface to the hardware latency detector. The window is the total time

1059 + * in us that will be considered one sample period. Conceptually , windows

1060 + * occur back -to-back and contain a sample width period during which

1061 + * actual sampling occurs.

1062 + */

1063 +static int debug_window_fopen(struct inode *inode , struct file *filp)

1064 +{

1065 + return 0;

1066 +}

1067 +

1068 +/**

1069 + * debug_window_fread - Read function for "window" debugfs entry





1074 + *

1075 + * This function provides a read implementation for the "window" debugfs

1076 + * interface to the hardware latency detector. The window is the total time



1079 + * actual sampling occurs. Can be used to read the total window size.

1080 + */

1081 +static ssize_t debug_window_fread(struct file *filp , char __user *ubuf ,


1083 +{

1084 + return simple_data_read(filp , ubuf , cnt , ppos , &data.sample_window);

1085 +}

1086 +

1087 +/**

1088 + * debug_window_fwrite - Write function for "window" debugfs entry





1093 + *

1094 + * This function provides a write implementation for the "window" debufds

1095 + * interface to the hardware latency detetector. The window is the total time



50


1098 + * actual sampling occurs. Can be used to write a new total window size. It

1099 + * is enfoced that any value written must be greater than the sample width

1100 + * size , or an error results.

1101 + */

1102 +static ssize_t debug_window_fwrite(struct file *filp ,


1104 + size_t cnt ,

1105 + loff_t *ppos)

1106 +{



1109 + u64 val = 0;

1110 + int err = 0;

1111 +




1115 +



1118 + if (0 != err)


1120 +


1122 + if (data.sample_width < val)

1123 + data.sample_window = val;

1124 + else {



1127 + }


1129 +

1130 + return csize;

1131 +}

1132 +

1133 +/*

1134 + * Function pointers for the "count" debugfs file operations

1135 + */

1136 +static const struct file_operations count_fops = {

1137 + .open = debug_count_fopen ,

1138 + .read = debug_count_fread ,

1139 + .write = debug_count_fwrite ,

1140 + .owner = THIS_MODULE ,

1141 +};

1142 +

1143 +/*

1144 + * Function pointers for the "enable" debugfs file operations

1145 + */

1146 +static const struct file_operations enable_fops = {

1147 + .open = debug_enable_fopen ,

1148 + .read = debug_enable_fread ,

1149 + .write = debug_enable_fwrite ,


1151 +};

1152 +

1153 +/*

1154 + * Function pointers for the "max" debugfs file operations

1155 + */

1156 +static const struct file_operations max_fops = {

1157 + .open = debug_max_fopen ,

1158 + .read = debug_max_fread ,

1159 + .write = debug_max_fwrite ,


1161 +};

1162 +

1163 +/*

1164 + * Function pointers for the "sample" debugfs file operations

1165 + */

1166 +static const struct file_operations sample_fops = {

1167 + .open = debug_sample_fopen ,

51


1168 + .read = debug_sample_fread ,

1169 + .release = debug_sample_release ,


1171 +};

1172 +

1173 +/*

1174 + * Function pointers for the "threshold" debugfs file operations

1175 + */

1176 +static const struct file_operations threshold_fops = {

1177 + .open = debug_threshold_fopen ,

1178 + .read = debug_threshold_fread ,

1179 + .write = debug_threshold_fwrite ,


1181 +};

1182 +

1183 +/*

1184 + * Function pointers for the "width" debugfs file operations

1185 + */

1186 +static const struct file_operations width_fops = {

1187 + .open = debug_width_fopen ,

1188 + .read = debug_width_fread ,

1189 + .write = debug_width_fwrite ,


1191 +};

1192 +

1193 +/*

1194 + * Function pointers for the "window" debugfs file operations

1195 + */

1196 +static const struct file_operations window_fops = {

1197 + .open = debug_window_fopen ,

1198 + .read = debug_window_fread ,

1199 + .write = debug_window_fwrite ,


1201 +};

1202 +

1203 +/**

1204 + * init_debugfs - A function to initialize the debugfs interface files

1205 + *

1206 + * This function creates entries in debugfs for "hwlat_detector", including

1207 + * files to read values from the detector , current samples , and the

1208 + * maximum sample that has been captured since the hardware latency

1209 + * dectector was started.

1210 + */

1211 +static int init_debugfs(void)

1212 +{


1214 +

1215 + debug_dir = debugfs_create_dir(DRVNAME , NULL);

1216 + if (! debug_dir)

1217 + goto err_debug_dir;

1218 +

1219 + debug_sample = debugfs_create_file (" sample", 0444,

1220 + debug_dir , NULL ,

1221 + &sample_fops);

1222 + if (! debug_sample)

1223 + goto err_sample;

1224 +

1225 + debug_count = debugfs_create_file ("count", 0444,


1227 + &count_fops);

1228 + if (! debug_count)

1229 + goto err_count;

1230 +

1231 + debug_max = debugfs_create_file ("max", 0444,


1233 + &max_fops);

1234 + if (! debug_max)

1235 + goto err_max;

1236 +

1237 + debug_sample_window = debugfs_create_file (" window", 0644,

52



1239 + &window_fops);

1240 + if (! debug_sample_window)

1241 + goto err_window;

1242 +

1243 + debug_sample_width = debugfs_create_file ("width", 0644,


1245 + &width_fops);

1246 + if (! debug_sample_width)

1247 + goto err_width;

1248 +

1249 + debug_threshold = debugfs_create_file (" threshold", 0644,


1251 + &threshold_fops);

1252 + if (! debug_threshold)

1253 + goto err_threshold;

1254 +

1255 + debug_enable = debugfs_create_file (" enable", 0644,

1256 + debug_dir , &enabled ,

1257 + &enable_fops);

1258 + if (! debug_enable)

1259 + goto err_enable;

1260 +

1261 + else {

1262 + ret = 0;

1263 + goto out;

1264 + }

1265 +

1266 +err_enable:

1267 + debugfs_remove(debug_threshold);

1268 +err_threshold:

1269 + debugfs_remove(debug_sample_width);

1270 +err_width:

1271 + debugfs_remove(debug_sample_window);

1272 +err_window:

1273 + debugfs_remove(debug_max);

1274 +err_max:

1275 + debugfs_remove(debug_count);

1276 +err_count:

1277 + debugfs_remove(debug_sample);

1278 +err_sample:

1279 + debugfs_remove(debug_dir);

1280 +err_debug_dir:

1281 +out:

1282 + return ret;

1283 +}

1284 +

1285 +/**

1286 + * free_debugfs - A function to cleanup the debugfs file interface

1287 + */

1288 +static void free_debugfs(void)

1289 +{

1290 + /* could also use a debugfs_remove_recursive */

1291 + debugfs_remove(debug_enable);

1292 + debugfs_remove(debug_threshold);

1293 + debugfs_remove(debug_sample_width);

1294 + debugfs_remove(debug_sample_window);

1295 + debugfs_remove(debug_max);

1296 + debugfs_remove(debug_count);

1297 + debugfs_remove(debug_sample);

1298 + debugfs_remove(debug_dir);

1299 +}

1300 +

1301 +/**

1302 + * detector_init - Standard module initialization code

1303 + */

1304 +static int detector_init(void)

1305 +{


1307 +

53


1308 + printk(KERN_INFO BANNER "version %s\n", VERSION);

1309 +

1310 + ret = init_stats ();

1311 + if (0 != ret)

1312 + goto out;

1313 +

1314 + ret = init_debugfs ();

1315 + if (0 != ret)

1316 + goto err_stats;

1317 +

1318 + if (enabled)

1319 + ret = start_kthread ();

1320 +

1321 + goto out;

1322 +

1323 +err_stats:

1324 + ring_buffer_free(ring_buffer);

1325 +out:

1326 + return ret;

1327 +

1328 +}

1329 +

1330 +/**

1331 + * detector_exit - Standard module cleanup code

1332 + */

1333 +static void detector_exit(void)

1334 +{

1335 + if (enabled) {

1336 + enabled = 0;

1337 + stop_kthread ();

1338 + }

1339 +

1340 + free_debugfs ();

1341 + ring_buffer_free(ring_buffer); /* free up the ring buffer */

1342 +

1343 +}

1344 +

1345 +module_init(detector_init);

1346 +module_exit(detector_exit);

1347 Index: xaf/MAINTAINERS

1348 ============ =======================================================

1349 --- xaf.orig/MAINTAINERS

1350 +++ xaf/MAINTAINERS

1351 @@ -2457,6 +2457 ,15 @@ W: http ://www.kernel.org/pub/linux/kerne

1352 S: Maintained

1353 F: drivers/hwmon/hdaps.c

13541355 +HARDWARE LATENCY DETECTOR

1356 +P: Jon Masters

1357 +M: [email protected]

1358 +W: http ://www.kernel.org/pub/linux/kernel/people/jcm/hwlat_detector/

1359 +S: Supported

1360 +L: linux [email protected]

1361 +F: Documentation/hwlat_detector.txt

1362 +F: drivers/misc/hwlat_detector.c

1363 +

1364 HYPERVISOR VIRTUAL CONSOLE DRIVER

1365 L: linuxppc [email protected]

1366 L: linux [email protected]

54

Annexe C

Configuration dynamique du noyauvia sysctl

sysctl est une interface qui permet d’examiner et de modifier dynamiquement lesparametres d’un systeme d’exploitation. Nous l’utilisons dans ce cas pour desactiver ourestreindre certaines fonctions du noyau Linux, afin que le programme d’analyse de per-formance temps reel vu en 3.4.2 puisse faire son office.

1 SYSCTL="/sbin/sysctl -q -e -w"23 # disable NMI watchdog4 $SYSCTL "kernel.nmi_watchdog =0"56 # Restrict stopmachine to cpu 0 (if supported)7 $SYSCTL "kernel.stopmachine_cpumask =0x1"89 # Restrict pagedrain to cpu 0 (if supported)

10 $SYSCTL "vm.pagedrain_cpumask =0x1"1112 # Disable scheduler RT throttling13 $SYSCTL "kernel.sched_rt_runtime_us =-1"1415 # Disable softlockup detection.16 # Ideally this should be a cpumask17 $SYSCTL "kernel.softlockup_thresh =-1"

55

Annexe D

Organisation de la recherche durant les 24 semaines deprojet

TN10 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31

SEP 2011

OCT 2011

NOV 2011

DEC 2011

JAN 2011

FEV 2011

MAR 2011

Prise en main de l’outil LTTng

Arrivée dans le laboratoire et découverte des notions de traçage système

Revue de littérature sur les systèmes temps réel et leurs principes

Recherche puis tests d’outils d’analyse de performance RT Rencontre avec Opal-RT et définition d’un nouvel outil…

… d’analyse de performance pour le temps réel

Recherches pour mettre en place l’outil tel que défini et faire face aux problèmes rencontrés lors de son développement

56

Raphaël Beamonte29, avenue Roger Salzmann13012 Marseille

+33 4 84 25 31 53+1 (438) 938-6879

[email protected]

ETUDIANT INGÉNIEUR EN TECHNOLOGIES MOBILES ET SYSTÈMES EMBARQUÉS

Compétences techniques :Langues étrangères : Anglais (Lu, écrit, parlé – niveau C1 [avancé] au test du BULATS écrit et

oral), Espagnol (notions)Langages de programmation : Python, TCL, Perl, C, PHP, AJAX, XHTML, CSS, J2EE/J2SE, bashSystèmes d'exploitation : Windows, GNU/Linux, AndroidLogiciels de développement : Boa-Constructor, Eclipse, Netbeans, nano/vimBase De Données : MySQL, MS Access (notions), Oracle SQL (notions)Méthodes d'analyse : UMLRéseaux : UDP, TCP / IP, Ethernet, LAN, Administration, DNS, Systèmes sans

fil/réseaux mobiles, Géolocalisation, SIP, VoIP, P2P

CO

MP

ÉT

EN

CE

S

2009(1 an)

Consultant en développement sur les systèmes d'information pour laFAO – ORGANISATION DES NATIONS UNIES POUR L'ALIMENTATION ET L'AGRICULTURE (Rome, Italie)

Supervision de la migration de version d'une plateforme Typo3 sur un serveur de production etparticipation à la maintenance de celle-ci.Développement de plugins pour cette plateforme, et d'autres utilitaires basés sur l'API Google Maps.Développement d'un système de base de données virtuelle utilisant XML.Conseil en base de données et en expressions régulières.

(Linux, PHP, JavaScript, XHTML, CSS, MySQL)

EX

PÉ

RIE

NC

E

2012(6 mois)

Chercheur en analyse de performance pour Linux dans le laboratoire DORSAL (Montréal, Canada), École Polytechnique de Montréal, Département de Génie Informatique et Génie Logiciel

Traçage noyau et userspace avec Linux Trace Toolkit next generation (LTTng) et les outils associés.Revue de littérature sur les méthodes existantes pour mettre en place des systèmes temps réel.Revue de littérature sur les outils permettant d'assurer les performances temps réel d'un système, ettests de ces outils.Developpement d'un nouvel outil d'analyse de performances temps reel en collaboration avec unpartenaire du projet.

2011(6 mois)

Consultant technico-fonctionnel en BI et CRM pour IBM – INTERNATIONAL BUSINESS MACHINES(Paris, France), Global Business Services (GBS), Service line Business Analytics & Optimization (BAO)

Etude des besoins du client, analyse et restructuration de rapports comptables et financiers pour lesadapter à ces derniers.Migrations et évolutions sur une plateforme Hyperion Financial Management.Développement en Python d'un logiciel de migration de fichiers pour cette plateforme.Développement en Java d'une application interfacée avec SOAP pour la gestion de notificationsauprès de l'Union Européenne pour le leader mondial des cosmétiques.

ST

AG

E

2012 Formation d'ingénieur en Systèmes d'Information et Télécommunications, dernière année desecond cycle

Université de Technologie de Troyes, FranceSpécialisé en Technologies Mobiles et Systèmes Embarqués.2009 – Obtention d'un mineur en entrepreneuriat, spécialisation juridique.2010 – Obtention d'un mineur en culture internationale et entreprise.

2007 Baccalauréat Scientifique spécialité MathématiquesLycée l'Olivier, Robert Coffy – Université Aix-Marseille, France – Mention AB

FO

RM

AT

ION

22 ans, Nationalité Française, Célibataire, Permis BCentres d'intérêts :

Voyages (France entière, Etats-Unis, Canada, Europe, Australie, Nouvelle Zélande)Lecture (Romans policiers)Ecriture (Articles humoristiques, Romans policiers)

Co-responsable en 2011 des journées portes ouvertes de l'UTTChargé de laboratoire du cours de système d'exploitation à l'EPM en 2012Administrateur de plusieurs serveurs à plus ou moins grosses infrastructures

DIV

ER

S

Powered by TCPDF (www.tcpdf.org)

Glossaire

Acronymes

CAD dollars canadiens. 2, 6

CTF Common Trace Format. 12, 16, Glossaire : CTF

DORSAL Distributed Open Reliable Systems Analysis Lab. 1, 2, 16, 17, 30

GIGL Genie Informatique et Genie Logiciel. 2, 5, 6

HRT Hard Real Time. 19

IRQ Interrupt Request. 8, 27, Glossaire : IRQ

LTT Linux Trace Toolkit. 8, 10

LTTng Linux Trace Toolkit next generation. 10, 13, 17, 30

SMI System Management Interrupt. 24, 25

SMP Symmetric MultiProcessing. 23, Glossaire : SMP

SRT Soft Real Time. 18

TN10 projet de fin d’etudes. 2

UST UserSpace Tracer. 12, 28

UTT Universite de technologie de Troyes. 1, 17, 30

EPM Ecole Polytechnique de Montreal. 2–6

Definitions

Journalisation Le concept de journalisation ou de logging designe l’enregistrement se-quentiel dans un fichier ou une base de donnees de tous les evenements affectant unprocessus particulier (application, activite d’un reseau informatique...). Le journal(en anglais log file ou log), designe alors le fichier contenant ces enregistrements. Engeneral dates et classes par ordre chronologique, ces derniers permettent d’analyserpas a pas l’activite interne du processus et ses interactions avec son environne-ment [21]. 7, 15

58

GLOSSAIRE

Mutex Un Mutex (exclusion mutuelle, de l’anglais MUTual EXclusion) est une primi-tive de synchronisation utilisee en programmation informatique pour eviter que desressources partagees d’un systeme ne soient utilisees en meme temps [20]. 21

Patch Un patch est une section de code que l’on ajoute a un logiciel, pour y apporterdes modifications mineures. 13, 59

Patchset Un patchset est un ensemble de patchs. 10, 13

Preemption La preemption est la capacite d’un systeme d’exploitation multitache aexecuter ou stopper une tache planifiee en cours en faveur d’une tache de prioritesuperieure. 21

59

Bibliographie

[1] Steve Brosky, Shielded CPUs : Real-Time Performance in Standard Linux, [en ligne],Disponible sur : http://www.linuxjournal.com/article/6900 (consulte le 18 jan-vier 2012).

[2] Steve Brosky and Steve Rotolo, Shielded Processors : Guaranteeing Sub-millisecondResponse in Standard Linux, [en ligne], Disponible sur : http://www.everstream.com/Libraries/docs_pdf/wp-shielded-cpu.pdf (consulte le 18 janvier 2012).

[3] Ecole Polytechnique de Montreal, Genie informatique et genie logiciel - Historique,[en ligne], Disponible sur : http://www.polymtl.ca/gigl/rensgen/historique.php (consulte le 15 janvier 2012). 2

[4] , OPAL-RT Technologies, [en ligne], Disponible sur : http://www.polymtl.ca/jc/entreprises/11OPALRT.php (consulte le 20 janvier 2012). 17

[5] , Programmes de Genie, [en ligne], Disponible sur : http://www.polymtl.ca/etudes/ (consulte le 15 janvier 2012). 4

[6] , Renseignements generaux, [en ligne], Disponible sur : http://www.polymtl.ca/rensgen/index.php (consulte le 15 janvier 2012). 2, 4

[7] , Statistiques de diplomation - 2010-2011, [en ligne], Disponible sur : http://www.polymtl.ca/sg/docs_officiels/dip_diplo.php?an=10-11 (consulte le 15janvier 2012). 2

[8] , Statistiques officielles inscription - automne 2011, [en ligne], Dispo-nible sur : http://www.polymtl.ca/sg/docs_officiels/tableau1.php?sessAn=a11 (consulte le 15 janvier 2012). 3

[9] David Cortesi and Susan Thomas, React real-time programmer’s guide, [en ligne],nov 2003, Disponible sur : http://techpubs.sgi.com/library/manuals/2000/

007-2499-011/pdf/007-2499-011.pdf (consulte le 17 novembre 2011).

[10] CRIAQ, CRIAQ - Consortium de recherche et d’innovation en aerospatiale au Que-bec, [en ligne], Disponible sur : http://www.criaq.aero/ (consulte le 20 janvier2012). 17

[11] Mathieu Desnoyers, Low-impact operating system tracing, Ph.D. thesis, Ecole Poly-technique de Montreal, Quebec, Canada, dec 2009. 10

[12] La Memoire du Quebec ® en ligne, Ecole polytechnique de Montreal-EPM (uni-versite), [en ligne], Disponible sur : http://memoireduquebec.com/wiki/index.

php?title=Ecole_polytechnique_de_Montreal-EPM_(universite) (consulte le15 janvier 2012). 3

60

http://www.linuxjournal.com/article/6900

http://www.everstream.com/Libraries/docs_pdf/wp-shielded-cpu.pdf

http://www.everstream.com/Libraries/docs_pdf/wp-shielded-cpu.pdf

http://www.polymtl.ca/gigl/rensgen/historique.php

http://www.polymtl.ca/gigl/rensgen/historique.php

http://www.polymtl.ca/jc/entreprises/11OPALRT.php

http://www.polymtl.ca/jc/entreprises/11OPALRT.php

http://www.polymtl.ca/etudes/

http://www.polymtl.ca/etudes/

http://www.polymtl.ca/rensgen/index.php

http://www.polymtl.ca/rensgen/index.php

http://www.polymtl.ca/sg/docs_officiels/dip_diplo.php?an=10-11

http://www.polymtl.ca/sg/docs_officiels/dip_diplo.php?an=10-11

http://www.polymtl.ca/sg/docs_officiels/tableau1.php?sessAn=a11

http://www.polymtl.ca/sg/docs_officiels/tableau1.php?sessAn=a11

http://techpubs.sgi.com/library/manuals/2000/007-2499-011/pdf/007-2499-011.pdf

http://techpubs.sgi.com/library/manuals/2000/007-2499-011/pdf/007-2499-011.pdf

http://www.criaq.aero/

http://memoireduquebec.com/wiki/index.php?title=�cole_polytechnique_de_Montr�al-�PM_(universit�)

http://memoireduquebec.com/wiki/index.php?title=�cole_polytechnique_de_Montr�al-�PM_(universit�)

BIBLIOGRAPHIE

[13] eLinux.org, Elc 2011 presentations, [en ligne], oct 2011, Disponible sur : http://elinux.org/ELC_2011_Presentations (consulte le 17 novembre 2011).

[14] Carsten Emde, Re : Latency problem, [en ligne], Disponible sur : http://

www.spinics.net/lists/linux-rt-users/msg07153.html (consulte le 21 janvier2012). 25

[15] Pierre Ficheux and Patrice Kadionik, Temps reel sous LINUX, [en ligne], Disponiblesur : http://uuu.enseirb.fr/~kadionik/embedded/linux_realtime/ (consultele 21 janvier 2012).

[16] , Temps reel sous linux (reloaded), [en ligne], oct 2008, Dis-ponible sur : http://www.unixgarden.com/index.php/comprendre/

temps-reel-sous-linux-reloaded (consulte le 17 novembre 2011).

[17] The Eclipse Foundation, Linux Tools Projet - LTTng Integration, [en ligne], Dispo-nible sur : http://www.eclipse.org/linuxtools/projectPages/lttng/ (consultele 21 janvier 2012). 11

[18] Wikimedia Foundation Inc., CAE (entreprise), [en ligne], Disponible sur : http:

//fr.wikipedia.org/wiki/CAE_(entreprise) (consulte le 20 janvier 2012). 17

[19] , Ecole polytechnique de Montreal, [en ligne], Disponible sur : http://fr.wikipedia.org/wiki/Ecole_polytechnique_de_Montreal (consulte le 15 janvier2012).

[20] , Exclusion mutuelle, [en ligne], Disponible sur : http://fr.wikipedia.org/wiki/Exclusion_mutuelle (consulte le 23 janvier 2012). 59

[21] , Historique (informatique), [en ligne], Disponible sur : http://fr.

wikipedia.org/wiki/Historique_(informatique) (consulte le 20 janvier 2012).58

[22] , Interruption materielle, [en ligne], Disponible sur : http://fr.wikipedia.org/wiki/Interruption_materielle (consulte le 20 janvier 2012).

[23] Tim Jones, Anatomy of real-time linux architectures, [en ligne], Disponible sur : http://www.ibm.com/developerworks/linux/library/l-real-time-linux/ (consultele 21 janvier 2012).

[24] Paul McKenney, A realtime preemption overview, [en ligne], aou 2005, Disponiblesur : http://lwn.net/Articles/146861/ (consulte le 17 novembre 2011).

[25] University of Toronto/Universite Laval, ARCHAMBEAULT, URGEL-EUGENE, [enligne], 2000, Disponible sur : http://www.biographi.ca/009004-119.01-f.php?id_nbr=6530 (consulte le 15 janvier 2012). 2

[26] osadl.org, Osadl project : Realtime linux, [en ligne], Disponible sur : https://

www.osadl.org/Realtime-Linux.projects-realtime-linux.0.html (consulte le17 novembre 2011).

[27] , Howto : Realtime-preempt kernel, [en ligne], nov 2009, Dispo-nible sur : https://www.osadl.org/fileadmin/dam/interface/docbook/howtos/kernel-rt.pdf (consulte le 17 novembre 2011).

[28] Politecnico di Milano (Dipartimento di Ingegneria Aerospaziale), RTAI, [en ligne],Disponible sur : https://www.rtai.org/ (consulte le 21 janvier 2012). 19

61

http://elinux.org/ELC_2011_Presentations

http://elinux.org/ELC_2011_Presentations

http://www.spinics.net/lists/linux-rt-users/msg07153.html

http://www.spinics.net/lists/linux-rt-users/msg07153.html

http://uuu.enseirb.fr/~kadionik/embedded/linux_realtime/

http://www.unixgarden.com/index.php/comprendre/temps-reel-sous-linux-reloaded

http://www.unixgarden.com/index.php/comprendre/temps-reel-sous-linux-reloaded

http://www.eclipse.org/linuxtools/projectPages/lttng/

http://fr.wikipedia.org/wiki/CAE_(entreprise)

http://fr.wikipedia.org/wiki/CAE_(entreprise)

http://fr.wikipedia.org/wiki/�cole_polytechnique_de_Montr�al

http://fr.wikipedia.org/wiki/�cole_polytechnique_de_Montr�al

http://fr.wikipedia.org/wiki/Exclusion_mutuelle

http://fr.wikipedia.org/wiki/Exclusion_mutuelle

http://fr.wikipedia.org/wiki/Historique_(informatique)

http://fr.wikipedia.org/wiki/Historique_(informatique)

http://fr.wikipedia.org/wiki/Interruption_mat�rielle

http://fr.wikipedia.org/wiki/Interruption_mat�rielle

http://www.ibm.com/developerworks/linux/library/l-real-time-linux/

http://www.ibm.com/developerworks/linux/library/l-real-time-linux/

http://lwn.net/Articles/146861/

http://www.biographi.ca/009004-119.01-f.php?id_nbr=6530

http://www.biographi.ca/009004-119.01-f.php?id_nbr=6530

https://www.osadl.org/Realtime-Linux.projects-realtime-linux.0.html

https://www.osadl.org/Realtime-Linux.projects-realtime-linux.0.html

https://www.osadl.org/fileadmin/dam/interface/docbook/howtos/kernel-rt.pdf

https://www.osadl.org/fileadmin/dam/interface/docbook/howtos/kernel-rt.pdf

https://www.rtai.org/

BIBLIOGRAPHIE

[29] redhat.org, Using the ftrace utility for tracing latencies, [en ligne], Disponible sur :http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_MRG/1.3/html/

Realtime_Tuning_Guide/sect-Realtime_Tuning_Guide-Realtime_Specific_

Tuning-Using_the_ftrace_Utility_for_Tracing_Latencies.html (consulte le17 novembre 2011).

[30] Wind River, Wind River - RTLinuxFree, [en ligne], Disponible sur : http://www.rtlinuxfree.com/ (consulte le 21 janvier 2012). 19

[31] Steven Rostedt, Secrets of the ftrace function tracer, [en ligne], jan 2010, Disponiblesur : http://lwn.net/Articles/370423/ (consulte le 17 novembre 2011).

[32] Frank Rowand, Real-time failure, [en ligne], avr 2009, Disponible sur : http:

//elinux.org/images/b/be/Real_time_linux_failure.pdf (consulte le 17 no-vembre 2011).

[33] LTTng Project Team, Screenshots, [en ligne], Disponible sur : http://lttng.org/lttv/screenshots (consulte le 21 janvier 2012). 11

[34] Peter Williams, Finding realtime linux kernel latencies, [en ligne], mar2010, Disponible sur : http://people.redhat.com/williams/latency-howto/

rt-latency-howto.txt (consulte le 17 novembre 2011).

[35] Xenomai, Xenomai : Real-Time Framework for Linux, [en ligne], Disponible sur :http://www.xenomai.org/ (consulte le 21 janvier 2012). 19

[36] Karim Yaghmour, Analyse de performance et caracterisation de comportement al’aide d’enregistrement d’evenements noyau, Master’s thesis, Ecole Polytechnique deMontreal, Quebec, Canada, juin 2001. 8

62

http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_MRG/1.3/html/Realtime_Tuning_Guide/sect-Realtime_Tuning_Guide-Realtime_Specific_Tuning-Using_the_ftrace_Utility_for_Tracing_Latencies.html



http://www.rtlinuxfree.com/

http://www.rtlinuxfree.com/

http://lwn.net/Articles/370423/

http://elinux.org/images/b/be/Real_time_linux_failure.pdf

http://elinux.org/images/b/be/Real_time_linux_failure.pdf

http://lttng.org/lttv/screenshots

http://lttng.org/lttv/screenshots

http://people.redhat.com/williams/latency-howto/rt-latency-howto.txt

http://people.redhat.com/williams/latency-howto/rt-latency-howto.txt

http://www.xenomai.org/

Documents

D eveloppement d’outils de trace d’ex ecution pour des syst emes …raphaelbeamonte.com/files/TN10.pdf · 2016. 3. 3. · Université de technologie de Troyes z 12 rue Marie Curie