Notions de temps

Cette section se propose d’introduire les concepts li´es `a la gestion du temps. Tel que nous l’avons mentionn´e pr´ec´edemment, la mise `a jour de l’horloge tombe sous la responsabilit´e du

syst`eme d’exploitation. Nous pr´esentons d’abord comment l’horloge est mise `a jour et main- tenue sous Linux ; nous introduisons ensuite une m´ethode existante pour la synchronisation de traces noyau de machines virtuelles.

2.7.1 Mesure et gestion du temps

Pour expliquer le m´ecanisme de mise `a jour du temps sous Linux, nous commen¸cons par pr´esenter comment le traceur LTTng assigne les estampilles de temps aux ´ev`enements qu’il enregistre. Celui-ci utilise les fonctions ktime_get() pour le tra¸cage en mode noyau, et clock_gettime() pour le tra¸cage en espace utilisateur. Ces deux fonctions utilisent les mˆemes variables en arri`ere-plan pour donner le temps du syst`eme, d’autant plus qu’une version VDSO [42] de clock_gettime() [43] a ´et´e impl´ement´ee pour x86. Leurs modes de fonctionnement sont similaires, et peut ˆetre d´ecortiqu´e en analysant le code source du noyau. Linux utilise une structure de type timespec pour maintenir le temps. Celle-ci contient deux champs, l’un pour les secondes et l’autre pour les nanosecondes, et est mise `a jour `a chaque interruption du system timer en l’incr´ementant par le temps ´ecoul´e depuis la derni`ere mise `a jour (donc depuis la derni`ere interruption livr´ee par le system timer ). Ce dernier repr´esente une interruption mat´erielle livr´ee par un composant externe au CPU, dont le but est de four- nir des interruptions diff´er´ees. Une composante APIC (Advanced Programmable Interrupt Controller) se situe `a proximit´e de chaque CPU et elle se charge de livrer des interruptions au CPU auquel elle est assign´ee. Celui-ci utilise un registre dans lequel il pr´ecise le d´elai avant la prochaine interruption, ce qui permet d’activer p´eriodiquement des interruptions. La fr´e- quence `a laquelle ces interruptions sont livr´ees est d´efinie dans Linux lors de la compilation du noyau par le param`etre de configuration CONFIG_HZ. Nous mentionnons que dans les syst`emes plus anciens, un seul contrˆoleur avait cette tˆache, le PIT (Programmable Interrupt Timer), dont les destinataires ´etaient l’ensemble des CPUs. Sur les syst`emes d’exploitation tickless (voir CONFIG_NO_HZ), la fr´equence de livraison des interruptions par le contrˆoleur APIC n’est pas r´eguli`ere, et chaque interruption doit ˆetre sp´ecifi´ee par le CPU. `A des fins de r´eduction de consommation d’´energie, le CPU ne demande d’interruption au APIC que lorsqu’un pro- cessus lui est assign´e par l’ordonnanceur. La livraison d’interruptions `a un CPU inactif est g´en´eralement inutile. Ainsi, pour un CPU au repos, aucune interruption n’est livr´ee.

Lorsqu’une fonction de temps est appel´ee, ktime_get() et clock_gettime() retournent la valeur des secondes ajust´ee selon une interpolation sur les nanosecondes pour combler le temps ´ecoul´e depuis la derni`ere mise `a jour.

2.7.2 Synchronisation des traces

Le plus grand obstacle `a la corr´elation des traces noyau des syst`emes invit´es et hˆote est la synchronisation de celles-ci. Notre analyse de pr´eemption doit ˆetre effectu´ee sur l’union de plusieurs traces enregistr´ees en mˆeme temps sur des syst`emes diff´erents. Cependant, tel qu’expliqu´e dans la section pr´ec´edente, le temps est mis `a jour ind´ependamment dans les diff´erents syst`emes. Une certaine marge d’erreur existe toujours, et la combinaison des ´ev`ene- ments de diverses traces en ordre chronologique ne r´esulte pas toujours en un flot d’ex´ecution coh´erent. Par exemple, un ´ev`enement dans une VM peut avoir une estampille de temps l´eg`e- rement sup´erieure `a celle d’un ´ev`enement d’ordonnancement qui “enl`eve” cette VM du CPU, ce qui r´esulte en une analyse erron´ee. Tel que pr´esent´e par [44], le TSC peut ˆetre utilis´e pour rem´edier `a ce probl`eme. Le TSC, ou TimeStamp Counter, est un registre sp´ecifique `a la famille x86 qui compte le nombre de cycles CPU depuis le d´emarrage de la machine, et peut ˆ

etre utilis´e `a des fins de mesure de temps `a haute pr´ecision. Lorsqu’il est lu depuis un sys- t`eme virtualis´e par assistance mat´erielle, la valeur du TSC est automatiquement d´ecal´ee en mat´eriel par le CPU par la valeur du champ TSC_OFFSET de la VMCS. En utilisant le traceur ftrace, les estampilles de temps attribu´ees `a chacun des ´ev`enements enregistr´es utilisent le TSC. En suivant les modifications du champ TSC_OFFSET, il est possible de ramener les ´ev`ene- ments de la trace du syst`eme invit´e `a la mˆeme ligne de temps que celle de l’hˆote, en assurant une coh´erence de la trace r´esultante. Cependant, cette approche pr´esente des probl`emes en terme de portabilit´e et de facilit´e d’utilisation. Tout d’abord, le registre TSC est sp´ecifique aux architectures x86, ce qui rend son utilisation impossible sur d’autres architectures. En- suite, l’enregistrement de la trace doit commencer avant le d´emarrage de la machine virtuelle pour obtenir l’´ev`enement initial de l’assignation du TSC_OFFSET. De plus, la perte poten- tielle d’´ev`enements lors du tra¸cage rend cette m´ethode inefficace, `a cause du risque de perdre un ´ev`enement de modification au TSC_OFFSET, il est donc aussi impossible d’interrompre le tra¸cage ce qui pourrait poser un probl`eme sur des environnements de production.