Frits Hoogland gehört zu den Autoren, bei denen mir die plausible Zusammenfassung ihrer Artikel große Mühe bereitet - was zunächst damit zu tun hat, dass sich diese Artikel häufig sehr intensiv mit OS-Fragestellungen beschäftigen und dorthin kann ich nur in beschränktem Umfang folgen. Diesmal aber hat der Herr Hooglands einen Artikel veröffentlicht, der sich mit der Umstellung der für die Zeitmessung im Wait Interface verwendeten Timer-Funktion beschäftigt - und da will ich mal wieder mein Glück in der Exzerpierung versuchen; oder wenigstens den Link unterbringen, um gelegentlich noch mal nachlesen zu können, was sich an dieser Stelle geändert hat. Dabei habe ich auch noch das Gefühl, dieses Thema hier schon mal in irgendeiner Form untergebracht zu haben, aber die beschränkten Suchfunktionen des Blogs haben mir an dieser Stelle nicht weiter geholfen.
Aber zum Thema: mit 11.2 wurde die Funktion gettimeofday() an vielen Stellen durch die Funktion clock_gettime() ersetzt. Dabei ist gettimeofday() "a best guess of the kernel of the wall clock time", während clock_gettime() ein monoton steigender Timer, "which means it is more precise and does not have the option to drift backward, which gettimeofday() can do in certain circumstances, like time adjustments via NTP." Im Artikel erläutert der Autor, warum er in der Kernel-Version seines Systems Schwierigkeiten hatte, diese Umstellung sichtbar zu machen, und wie das über den GNU Debugger (gdb) möglich ist. Durch dieses Vorgehen kann er auch bestimmen, dass die für clock_gettime() verwendete Verfahrensweise CLOCK_MONOTONIC ist - laut Dokumentation gäbe es da eine Reihe anderer Zeitmessungsalternativen (wie CLOCK_REALTIME, CLOCK_PROCESS_CPUTIME_ID, CLOCK_THREAD_CPUTIME_ID, CLOCK_MONOTONIC_RAW etc.). Durch die Verwendung dieser Basis ergibt sich auch, dass die Granularität des Wait Interfaces auf Mikrosekunden-Ebene liegt. Die weitere Untersuchung zeigt, dass das Wait Interface selbst im gegebenen Testfall einen Overhead von etwa 6 Mikrosekunden hervorgerufen hat. Dieser Overhead erklärt auch, wieso das Wait Interface zur Messung bestimmter Operationen nicht geeignet ist, deren Laufzeiten so niedrig sind, dass dieser Overhead die eigentlichen Ergebnisse massiv überlagern würde. Ein Beispiel sind einzelne Latch-Zugriffe, die auf OS-Ebene durchaus sinnvoll gemessen werden können, deren Laufzeiten aber deutlich niedriger sind als der Overhead des Wait Interfaces. Um genauere Informationen zur CPU-Nutzung zu erhalten ist man demnach früher oder später dazu gezwungen, auf die OS-Utilities (systemtap, perf, flame graphs etc.) zurückzugreifen, die ich mir offenbar gelegentlich genauer ansehen müsste.
Keine Kommentare:
Kommentar veröffentlichen