Draußen ist alles hellgrau, leichter Schnee treibt quer über den Balkon, und der Wind pfeift ordentlich. 1,6 °C laut Anzeige, fühlt sich aber schärfer an. Genau deshalb bleib ich heute mit dem Laptop am Fenster sitzen – keine neuen wilden Runs, sondern das nachholen, was mir gestern gefehlt hat: zwei harte Snapshots rund um den Switch. Sonst tapp ich weiter im Nebel „Offset ist da“, ohne zu wissen warum.
Zwei Snapshots statt Bauchgefühl
Ich hab do_clocksource_switch() so instrumentiert, dass ich pro Switch zwei Zustände einfriere:
- Snapshot A: direkt nach dem Switch-Commit, aber explizit vor
baseline_recalc - Snapshot B: direkt nach
baseline_recalc
In beiden logge ich zusammengehörig:
clocksource_id und separat die dazugehörigen base/mult/shift – plus ein Flag, ob der erste tkread danach retry‑frei war.
Erster sauberer Batch: NY106-2snap, 60 Switch-Fälle.
Ergebnis (und ein kleiner Aha‑Moment)
In 11 von 60 Fällen sehe ich schon in Snapshot A eine inkonsistente Kombination: clocksource_id passt nicht zu base/mult/shift. Snapshot B ist danach wieder sauber.
Und jetzt das Wichtige: Genau diese 11 Fälle korrelieren mit dem ≈ 1,111 s Offset im ersten retry‑freien Read.
Heißt für mich: baseline_recalc ist nicht der Ursprung des falschen Mix. Sie glättet ihn eher. Das Problem entsteht davor (oder parallel) – irgendwo im Übernahmefenster der Parameter. Das schließt den offenen Faden von gestern zumindest teilweise: Der Offset kommt nicht aus der Recalc selbst. Das fühlt sich gerade ziemlich rund an.
Mini‑Extra: Governor als Kontrollversuch
Weil der Wind heute echt unangenehm ist, kein Außenaufbau. Stattdessen ein kontrollierter Test:
- gleicher Snapshot‑Setup
- CPU‑Governor einmal performance, einmal powersave
Erwartung passt: In powersave steigt die Switch‑Rate. Aber: Der Anteil der „Mix‑in‑A“-Fälle bleibt ähnlich. Mehr Gelegenheiten, ja – aber nicht die Ursache.
Nächster Schritt
Ich bau in die BPF‑Logs noch eine eindeutige Zuordnung ein (Pointer/Seq für das timekeeper‑Struct oder ein stabiles ID‑Äquivalent). Ich will sicher wissen, ob ich wirklich denselben Datensatz sehe – oder ob ich kurz zwei Strukturen überkreuze.
Und an euch, falls jemand das liest und sowas schon mal gesehen hat: Habt ihr schon erlebt, dass ID und (base/mult/shift) kurzzeitig auseinanderlaufen? Und wo würdet ihr im Timekeeping zuerst nach einem fehlenden Barrier‑ oder Seqcount‑Handling suchen?
Für heute reicht’s. Zwei Snapshots haben mehr gebracht als zehn weitere Runs. Vielleicht ist das genau die Art Präzision, die man später mal brauchen kann … pack ma’s. 🚀
Diagramme
Begriffe kurz erklärt
- do_clocksource_switch(): Diese Kernel-Funktion wechselt die aktuelle Zeitquelle, etwa von der Systemuhr zu einer präziseren High-Resolution-Clock.
- baseline_recalc: Hier wird ein Grundwert oder Referenzpunkt neu berechnet, zum Beispiel um Messabweichungen bei Zeitstempeln zu korrigieren.
- clocksource_id: Das ist eine Kennnummer, mit der der Kernel die aktuell genutzte Zeitquelle eindeutig identifiziert.
- CPU-Governor: Ein CPU-Governor steuert die Prozessorfrequenz dynamisch, um zwischen Stromsparmodus und Höchstleistung zu wechseln.
- BPF-Logs: Das sind Protokolle aus BPF-Programmen, die helfen, Abläufe im Kernel oder in Netzwerkskripten zu überwachen.
- timekeeper-Struct: Diese Datenstruktur speichert im Kernel alle wichtigen Infos zur aktuellen Systemzeit und deren Berechnung.
- Barrier-Handling: Beim Barrier-Handling sorgt der Kernel dafür, dass Speicher- oder CPU-Operationen in der richtigen Reihenfolge ablaufen.
- Seqcount-Handling: Seqcount-Handling dient dazu, Datenkonsistenz bei gleichzeitigen Lese- und Schreibzugriffen auf gemeinsame Variablen sicherzustellen.
