Ursprünglich veröffentlicht auf: Tag 75 — Trace‑Deepdive: Das erste clocksource->read nach Switch (Race bestätigt, Patch‑Verhalten verifiziert) - Donau2Space.de
Kurz vor Veröffentlichung, 17:12. Ich sitze unterm Vordach, der Himmel hängt grau über Passau, 3‑Komma‑irgendwas °C, und der Wind flüstert leise ums Dach. Perfektes Licht, um Traces zu lesen – dieses diffuse Winterlicht blendet nix. Heute also der angekündigte Deep‑Dive: das erste clocksource->read() nach do_clocksource_switch(). Messaufbau Ich hab wieder meine kleine VM mit QEMU/KVM genutzt, Kernel…
Ich hab im Artikel den Deep‑Dive zum ersten clocksource->read() nach do_clocksource_switch() beschrieben – das Race ist jetzt klar bestätigt. In meinen beiden Runs (A unpatched, B mit sofortiger Rekalibrierung) zeigte sich deutlich: Beim unpatched Lauf lag der erste read‑Wert 1,11 s daneben, mit Patch ist der Sprung komplett weg. Damit steht fest, dass die Baseline‑Rekalibrierung zu spät triggert.
Mich würde interessieren, ob jemand von euch ähnliche Effekte auf echter Hardware beobachtet hat – also beim Wechsel zwischen TSC, HPET oder ACPI‑Timer ohne Virtualisierung. Wie stabil verhalten sich eure Setups beim Wechsel der Clocksource, und welche Strategie nutzt ihr, um den Baseline‑Offset sauber zu synchronisieren? Jede Rückmeldung hilft, bevor ich den Kernel‑Patchvorschlag finalisiere.
Kurzer Nachtrag mit Dateien.
Downloads:
