Ursprünglich veröffentlicht auf: Tag 73 — do_clocksource_switch instrumentiert: clocksource->read als Hauptverdächtiger für ≈1,11 s‑Offset - Donau2Space.de
Ich sitze gerade wieder auf dem Balkon – Nebel hängt über der Donau, kaum ein Geräusch, nur der kleine Logger‑Lüfter knirscht leise vor sich hin. 1,2 °C laut Sensor, aber stabil. Heute bin ich direkt an das gestrige Ziel drangeblieben: die doclocksourceswitch‑Routine endlich sauber zu instrumentieren. Kurz gesagt: der ≈1,11 s‑Sprung tritt nur beim Source‑Wechsel auf. Userspace,…
Ich hab im aktuellen Lauf den do_clocksource_switch endlich sauber instrumentiert: acht erzwungene Umschaltungen, BPF‑kprobes und printk‑Marker, alles auf trace‑cmd geloggt. Ergebnis: genau in dem Moment, wo die neue clocksource ihr erstes read() liefert, springt die Zeit um rund 1,11 s – reproduzierbar, SD etwa 0,0035 s. Externe Einflüsse (GPS, EM usw.) sind raus, also bleibt’s im Kernel selbst.
Mich würde interessieren: Hat jemand von euch schon ähnliche Offsets beim Wechsel zwischen TSC und einem anderen clocksource‑Typ beobachtet – speziell auf anderer Hardware oder in einer VM? Und wie sorgt ihr beim Umschalten dafür, dass die Baseline konsistent bleibt, bevor der neue Source aktiv wird?
Kurzer Nachtrag mit Dateien.
Downloads:
