Ich versuche wirklich zu verstehen, warum unsere Gast-VMs den kvm-clock-Treiber nicht verwenden, „wie sie es sollten“. Sie führen RHEL 7.2, glibc-2.17, kern 3.10.0 aus. Programme wie date und perl -e 'print time' Holen Sie sich die aktuelle Zeit, aber tun Sie dies ohne einen Systemaufruf. Dies wird mit strace und ltrace bestätigt und durch die Verwendung von gdb und Tracing durch Assembly bestätigt, wodurch der syscall umgangen wurde und stattdessen eine Anweisung namens rtdscp ausgeführt .
Ist das ein Optimierungsversuch der Glibc-Autoren? Gibt es eine Möglichkeit, dies zu deaktivieren und glibc-Aufrufe zu zwingen, den Systemaufruf zu machen (kurz vor LD_PRELOAD-Hacks)?
AKTUALISIEREN 14.10.2016:
Nach Durchsicht des neuesten POSIX-Entwurfs ist ein Teil der Antwort klar:Es gibt eine Möglichkeit, die Uhr von der CPU anzufordern, aber GNU glibc hat diese Implementierung ihren Benutzern fälschlicherweise aufgezwungen. Die Problemumgehung besteht darin, den Systemaufruf direkt aufzurufen. (Booooh)
Wenn _POSIX_CPUTIME definiert ist, müssen Implementierungen Uhr-ID-Werte unterstützen, die durch Aufrufen von clock_getcpuclockid() erhalten werden, die die CPU-Zeituhr eines gegebenen Prozesses darstellen. Implementierungen sollen auch den speziellen clockid_t-Wert CLOCK_PROCESS_CPUTIME_ID unterstützen, der die CPU-Zeituhr des aufrufenden Prozesses darstellt, wenn einer von clock_() oder timer_ aufgerufen wird () Funktionen.
Angesichts der Tatsache, dass der Benutzer dies tun kann. Gibt es ein echtes Argument gegen die Vorstellung, dass wenn clock_id auf CLOCK_REALTIME eingestellt ist , soll der Systemaufruf verwendet werden?
Akzeptierte Antwort:
Ich denke, der Grund, warum Sie keinen Systemaufruf sehen, ist, dass einige Linux-Systemaufrufe (insbesondere solche, die sich auf die Zeit beziehen, wie gettimeofday(2) und time(2) ) haben spezielle Implementierungen durch das vDSO, das etwas optimierte Implementierungen einiger Syscalls enthält:
Das „vDSO“ (Virtual Dynamic Shared Object) ist eine kleine gemeinsam genutzte Bibliothek
die der Kernel automatisch in den Adressraum aller
User-Space-Anwendungen abbildet.
Es gibt einige Systemaufrufe, die der
Kernel bereitstellt, die User-Space-Code häufig verwendet, bis zu dem Punkt,
dass solche Aufrufe die Gesamtleistung dominieren können. Dies liegt
sowohl an der Häufigkeit des Aufrufs als auch an dem Kontextwechsel
Overhead, der sich aus dem Verlassen des Benutzerbereichs und dem Betreten des
Kernels ergibt.
Jetzt erwähnt das Handbuch, dass die erforderlichen Informationen nur im Speicher abgelegt werden, damit ein Prozess direkt darauf zugreifen kann (die aktuelle Uhrzeit ist schließlich kein großes Geheimnis). Ich kenne die genaue Implementierung nicht und kann nur Vermutungen über die Rolle des Zeitstempelzählers der CPU im it anstellen.
Es ist also nicht wirklich glibc, der eine Optimierung durchführt, sondern der Kernel. Es kann durch Setzen von vdso=0 deaktiviert werden auf der Kernel-Befehlszeile, und es sollte möglich sein, es zu kompilieren. Ich kann jedoch nicht finden, ob es möglich ist, es auf der glibc-Seite zu deaktivieren (zumindest ohne die Bibliothek zu patchen).
Es gibt eine Menge anderer Informationen und Quellen zu dieser Frage auf SE.
Sie sagten in der Frage:
Nach Durchsicht des neuesten POSIX-Entwurfs ist ein Teil der Antwort klar:Es gibt einen Weg, die Uhr von der CPU anzufordern, aber GNU glibc hat diese Implementierung ihren Benutzern fälschlicherweise aufgezwungen.
Was ich für eine ziemlich gewagte Aussage halte. Ich sehe keine Beweise dafür, dass Benutzern irgendetwas „zu Unrecht aufgezwungen“ wird, zumindest nicht zu ihrem Nachteil. Die vDSO-Implementierung wird von fast jedem Linux-Prozess verwendet, der auf aktuellen Systemen läuft, was bedeutet, dass wenn es nicht richtig funktioniert hätte, schon einige sehr laute Beschwerden zu hören gewesen wären. Auch hast du selbst gesagt, dass die erhaltene Uhrzeit stimmt.
Das Zitat, das Sie aus clock_gettime geben Das Handbuch scheint nur zu erwähnen, dass der Aufruf Uhr-IDs unterstützen muss, die von clock_getcpuclockid zurückgegeben werden , nichts über das Verhalten von CLOCK_REALTIME oder gettimeofday .