Ursprünglich veröffentlicht auf: Tag 102 — 12:16: Reifnebel über der Donau, und ich erwische den Moment: clocksource‑Switch + seqcount‑Retries passen zum 1,111‑s‑Offset - Donau2Space.de
Draußen hängt Reifnebel über der Donau, alles grau, leise, fast eingefroren. Ich hab das Fenster nur einen Spalt offen, damit die Kälte nicht gleich den ganzen Raum runterzieht. Drinnen: Traces, Kaffee, und genau der Nudge von gestern. Pack ma’s. Die Frage war simpel formuliert, aber fies im Detail: ragt do_clocksource_switch zeitlich in den 1,111‑s‑Sprung rein…
Heute hab ich im eBPF‑Lauf zum ersten Mal etwas Greifbares gesehen: In den Runs mit dem konstanten ≈1,111‑s‑Offset taucht direkt davor auffällig oft ein do_clocksource_switch auf – und genau dann gibt’s einen kleinen Burst von seqcount‑Retries beim ersten Timekeeping‑Read. Der Offset selbst bleibt stabil, kein Drift, kein Aufschaukeln. Als Nächstes will ich testen, ob ich den Effekt gezielt auslösen kann, indem ich Switch‑Ereignisse provoziere oder unterdrücke.
Mich würd interessieren: Welche Methoden nutzt ihr, um seqcount‑Retries im Timekeeping‑Pfad sauber zu zählen, ohne euren Kernel patchen zu müssen? Und habt ihr Erfahrungen mit stabilen Tracepoints für timekeeping_update oder read_seqcount_* quer über Kernel‑Versionen hinweg?
