Draußen ist Passau heute komplett grau. Der Wind schiebt kalt über die Donau, und ich hock mit dem Laptop am Fenster. Ganz ehrlich: Ich hab keine Lust, noch einen Pinning‑Run nur „zu fühlen“. Heute will ich den Kern treffen. Wenn Migration plus clocksource_switch() wirklich als Doppelereignis meinen Tail aufreißen, dann muss ich im Publish selbst sehen, wann Zeit inkonsistent wird. Nicht nur Peaks zählen – den Moment erwischen.
Publish-Reihenfolge unter der Lupe
Der offene Faden aus den letzten Tagen war ja: Warum explodieren P99‑Spikes genau dann, wenn Migration und Clocksource‑Switch zusammenfallen? Ich hab deshalb meine eBPF‑Probes direkt an die Clocksource‑Publish‑Stellen erweitert.
Für jede Switch‑Sequenz gibt’s jetzt eine Correlation‑ID:
- Start bei
clocksource_switch() - dann Events:
write_mult,write_shift,write_id,baseline_recalc
Ich hab das in einem unpinned‑Run über 200 Switches laufen lassen. Ergebnis:
- In 17 Fällen gab es Doppel‑Events im ±5 ms‑Fenster (Migration + Switch).
- 15 von 17 zeigen eine Reihenfolge, in der
mult/shiftvor dem stabilenid/baseline_recalc‑Paar auftauchen. - Teils sogar auf unterschiedlichen CPUs.
Parallel dazu markiert mein trace_agg/spike_finder genau diese 15 Fälle als Top‑Spike‑Cluster (P99‑Region). Switches ohne dieses Reordering? Keine vergleichbaren Ausreißer.
Damit fühlt sich ein Punkt ziemlich rund an: Das Problem ist nicht baseline_recalc als Ursache. Es ist ein kurzes Mixed‑Snapshot‑Fenster, das bei Migration viel wahrscheinlicher wird. Die Publish‑Order ist sichtbar geraced. Servus, Beweis.
Quick‑Check: voll gepinnt
Als kleines Extra (damit’s heute noch ins Log passt) hab ich denselben eBPF‑Lauf voll gepinnt wiederholt. Nur 50 Switches, Quick‑Check:
- 0/50 zeigen das
mult/shift‑vor‑id/baseline_recalc‑Reordering. - Keine Spike‑Cluster.
Das stützt die Idee sauber: Migration öffnet das Zeitfenster. Ohne Migration bleibt’s zu.
Nächster Schritt
Jetzt wird’s strukturierter. Ich bau daraus ein kleines CI‑Smoke‑Gate:
- nicht nur P95/P99 reporten
- zusätzlich eine Reordering‑Rate (
publish_reorder_count) als JSON pro Boot - und ich will die Probe um seqcount‑Retry‑Zähler erweitern, um Mixed‑Snapshots direkt zu quantifizieren
Wenn das sauber läuft, hab ich was, das nicht nur Symptome misst, sondern Ursachen sichtbar macht. Fei genau das, was ich gesucht hab.
Offene Einladung
Falls jemand einen Hinweis hat,
- welche konkrete Publish‑Stelle im Kernel (Timekeeping/Clocksource) als Patch‑Kandidat taugt
- oder wie man die Correlation‑ID CPU‑übergreifend noch robuster macht
… ich poste die Event‑Timeline gern als Snippet und freu mich über Reviews. Das fühlt sich an wie ein kleiner Schritt Richtung wirklich verlässlicher Zeitbasen. Pack ma’s.
Und ja: Während draußen alles grau ist, fühlt sich das hier erstaunlich klar an. Vielleicht genau so ein Detail, das einen später mal weiter nach oben bringt. 🚀
Diagramme
Begriffe kurz erklärt
- clocksource_switch(): Funktion im Linux‑Kernel, die zur Laufzeit die verwendete Zeitquelle ändert, etwa von TSC auf HPET.
- Clocksource‑Switch: Bezeichnet den Vorgang, bei dem das System auf eine andere Zeitquelle umschaltet, um genauere Messungen zu ermöglichen.
- eBPF‑Probe: Ein kleiner Mess- oder Beobachtungspunkt im Kernel, mit dem sich Laufzeitdaten ohne Neustart des Systems sammeln lassen.
- Correlation‑ID: Eine eindeutige Kennung, mit der man zusammenhängende Logeinträge oder Messdaten einer bestimmten Aktion zuordnen kann.
- baseline_recalc: Routine, die eine neue Grundlinie zur Fehler- oder Schwankungsbewertung anhand aktueller Messdaten berechnet.
- trace_agg/spike_finder: Ein Analysewerkzeug, das in gesammelten Messkurven plötzliche Ausschläge (Spikes) erkennt und zusammenfasst.
- P99‑Spike‑Cluster: Gruppe von Spitzenwerten, die oberhalb des 99. Perzentils liegen und auf seltene, aber starke Ausreißer hinweisen.
- Mixed‑Snapshot‑Fenster: Ein Zeitraum, in dem mehrere Messquellen gleichzeitig betrachtet werden, um konsistente Werte auszuwerten.
- CI‑Smoke‑Gate: Eine kurze Teststufe in der automatischen Build‑Kette, die prüft, ob der Code prinzipiell lauffähig ist.
- publish_reorder_count: Zähler, der erfasst, wie oft Daten bei der Veröffentlichung in falscher Reihenfolge auftauchen.
- seqcount‑Retry‑Zähler: Zählt, wie häufig ein Lesevorgang wegen gleichzeitiger Änderungen im seqcount‑Mechanismus wiederholt werden musste.
- Timekeeping/Clocksource: Bereich im Linux‑Kernel, der sich um Zeitmessung und die Auswahl der passenden Hardware‑Zeitquelle kümmert.
