J'essaie vraiment de comprendre pourquoi nos machines virtuelles invitées n'utilisent pas le pilote kvm-clock "comme elles sont censées le faire". Ils exécutent RHEL 7.2, glibc-2.17, kern 3.10.0. Des programmes tels que date et perl -e 'print time' obtenir l'heure actuelle, mais le faire sans faire d'appel système. Ceci est confirmé avec strace et ltrace et encore confirmé en utilisant gdb et en suivant l'assemblage qui a contourné le syscall et à la place exécuté une instruction appelée rtdscp .
Est-ce une tentative d'optimisation par les auteurs de la glibc ? Existe-t-il un moyen de désactiver cela et de forcer les appels glibc à effectuer l'appel système (à moins de hacks LD_PRELOAD) ?
MISE À JOUR 2016-10-14 :
Après avoir examiné le dernier brouillon POSIX, une partie de la réponse est claire :il existe un moyen de demander l'horloge au processeur, mais la glibc GNU a imposé à tort cette implémentation à ses utilisateurs. La solution consiste à invoquer directement l'appel système. (Booooh)
Si _POSIX_CPUTIME est défini, les implémentations doivent prendre en charge les valeurs d'ID d'horloge obtenues en appelant clock_getcpuclockid(), qui représentent l'horloge CPU d'un processus donné. Les implémentations doivent également prendre en charge la valeur spéciale clockid_t CLOCK_PROCESS_CPUTIME_ID, qui représente l'horloge CPU du processus appelant lors de l'appel de l'un des clock_() ou timer_ () fonctions.
Étant donné que l'utilisateur peut Y a-t-il un argument réel contre l'idée que si clock_id est défini sur CLOCK_REALTIME , l'appel système doit être utilisé ?
Réponse acceptée :
Je pense que la raison pour laquelle vous ne voyez pas d'appel système se produire, c'est que certains appels système Linux (surtout ceux liés au temps, comme gettimeofday(2) et time(2) ) ont des implémentations spéciales via le vDSO, qui contient des implémentations quelque peu optimisées de certains appels système :
Le "vDSO" (objet partagé dynamique virtuel) est une petite bibliothèque partagée
que le noyau mappe automatiquement dans l'espace d'adressage de toutes
les applications de l'espace utilisateur.Le noyau fournit certains appels système que le code de l'espace utilisateur finit par utiliser fréquemment, au
point où de tels appels peuvent dominer les performances globales. Cela est dû
à la fois à la fréquence de l'appel ainsi qu'au surcoût de changement de contexte
qui résulte de la sortie de l'espace utilisateur et de l'entrée dans le
noyau.
Maintenant, le manuel mentionne que les informations requises sont simplement placées en mémoire afin qu'un processus puisse y accéder directement (l'heure actuelle n'est pas vraiment un secret, après tout). Je ne connais pas l'implémentation exacte et je ne pouvais que deviner le rôle du compteur d'horodatage du processeur dans celui-ci.
Donc, ce n'est pas vraiment la glibc qui fait une optimisation, mais le noyau. Il peut être désactivé en définissant vdso=0 sur la ligne de commande du noyau, et il devrait être possible de le compiler. Cependant, je ne trouve pas s'il est possible de le désactiver du côté de la glibc (au moins sans patcher la bibliothèque).
Il existe un tas d'autres informations et sources sur cette question sur SE.
Vous avez dit dans la question :
Après avoir examiné le dernier brouillon POSIX, une partie de la réponse est claire :il existe un moyen de demander l'horloge au processeur, mais la glibc GNU a imposé à tort cette implémentation à ses utilisateurs.
Ce que je pense est une déclaration plutôt audacieuse. Je ne vois aucune preuve de "forcer à tort" quoi que ce soit sur les utilisateurs, du moins pas à leur désavantage. L'implémentation de vDSO est utilisée par presque tous les processus Linux exécutés sur les systèmes actuels, ce qui signifie que si cela ne fonctionnait pas correctement, des plaintes très bruyantes auraient déjà été entendues. De plus, vous avez dit vous-même que l'heure reçue est correcte.
La citation que vous donnez de clock_gettime le manuel semble seulement mentionner que l'appel doit prendre en charge les identifiants d'horloge renvoyés par clock_getcpuclockid , rien sur le comportement de CLOCK_REALTIME ou gettimeofday .