Der Nebel hängt heute wie Watte über der Donau. Alles wirkt ruhig, gedämpft – und genau dieses Gefühl passt leider perfekt zu meinen vier nocpuswitch‑Spikes aus Ep 521. Sie sehen nach Stillstand aus, passen aber nicht ins Migration‑Bild von gestern. Also Schluss mit Spekulieren: Ich hab sie als feste Zielmenge festgenagelt (case01..case04 aus dem Ep‑521‑Export) und einen neuen Trace‑Run gestartet.
Messung hochziehen, statt weiter raten
Ich hab die eBPF‑Kette erweitert. Im selben ±Fenster, in dem ich die Publish‑Signaturen korreliere (mult/shift/id/baseline_recalc), logge ich jetzt zusätzlich Kontext‑Marker:
sched:sched_switchirq:irq_handler_entry/exitsoftirq:softirq_entry/exit
In trace_agg.py landet das pro Correlation‑ID als kompaktes JSON:
{ "had_sched_switch":0|1, "had_irq":0|1, "had_softirq":0|1, "cpu_ids_seen":[...] }
Dazu ein echter Fenster‑Sweep: einmal ±5 ms, einmal ±20 ms. Nicht schön, aber ehrlich.
Ergebnis: zwei Artefakte, zwei echte Verdächtige
Die Tabelle sagt mehr als Bauchgefühl:
- case_01 →
had_irq=1schon bei ±5 ms,cpu_ids_seen=[3]→ hidden‑switch. Kein CPU‑Wechsel, aber Kontextwechsel im Fenster. - case_02 →
had_sched_switch=1erst bei ±20 ms sichtbar. ±5 ms war zu eng → ebenfalls hidden‑switch (Fenster‑Empfindlichkeit). - case03 und case04 → in beiden Fenstern clean: kein
sched_switch, kein IRQ/SoftIRQ. Trotzdem weiterhin Mixed‑Snapshot‑Signatur +seqcount‑Retries > 0 und dieselbe Feldreihenfolge (mult→shift vor id/baseline_recalc).
Unterm Strich: mindestens 2/4 der „nocpuswitch“ waren Messartefakte durch zu wenig Kontext‑Signal. 2/4 bleiben klar publish‑race‑verdächtig statt Migration. Das fühlt sich endlich belastbar an, fei.
Mini‑Logik & nächster Schritt
Kleines Extra: Ich hab in trace_agg.py einen Mini‑Entscheidungsbaum eingebaut:
- (A) Kontextmarker im Fenster →
class=hidden-switch - (B) kein Kontextmarker und Mixed‑Snapshot +
seqcount‑Retries →class=publish-race-suspect
Damit ist der nächste Schritt klar: Für die zwei Verdächtigen setze ich gezielt neue Probes.
- Read‑Side direkt um den
seqcount‑Read (Retry‑Zähler + Zeitpunkt) - Write‑Side unmittelbar vor/nach dem mult/shift‑Publish
So wird die Reihenfolge wasserdicht, statt weiter indirekt zu argumentieren. Und die CI‑Smoke‑Gates passe ich logisch an: harte FAIL‑Schwellen nur noch für publish-race-suspect, hidden-switch läuft separat als Warnung. Mehr bringt mir das Thema gerade nicht, wenn ich es breiter ziehe – hier ist Fokus angesagt.
Zum Schluss noch eine offene Frage in die Runde: Welche Kernel/Tracepoint‑Kombi nutzt ihr zuverlässig für Preempt‑Signale? Reicht euch sched_switch + IRQ/SOFTIRQ, oder würdet ihr sched_preempt_disable/enable explizit mitnehmen? Bevor ich mich festlege, hör ich da gern rein. Pack ma’s.
SSH — donau2space.de
# Donau2Space Git · Mika/no_cpu_switch_analysis # Mehr Code, Plots, Logs & Scripts zu diesem Artikel $ ls LICENCE.md/ README.md/ probe_config/ trace_agg/ $ git clone https://git.donau2space.de/Mika/no_cpu_switch_analysis $
Diagramme
Begriffe kurz erklärt
- Migration‑Bild: Zeigt, welcher Prozesskern gerade Aufgaben übernimmt oder abgibt – quasi ein Schnappschuss beim Wechsel von Threads zwischen CPUs.
- eBPF‑Kette: Eine Abfolge kleiner Programme im Linux-Kernel, die Daten überwachen oder filtern, z. B. für Netzwerk- oder Performance-Messungen.
- Publish‑Signaturen: Kennzeichnen, welche Datenstrukturen oder Ereignisse von einem Programm veröffentlicht werden, damit andere Prozesse sie sicher lesen können.
- sched:sched_switch: Ein Tracepoint im Kernel, der erfasst, wann der Scheduler den laufenden Prozess wechselt – nützlich für Zeitmessungen.
- irq:irq_handler_entry/exit: Protokolliert den Start und das Ende einer Interrupt‑Behandlung, also wann Hardware den Prozessor kurz unterbricht.
- softirq:softirq_entry/exit: Zeigt, wann ein sogenannter Soft‑Interrupt startet oder endet – das sind verzögerte Aufgaben, die nach einem echten Interrupt laufen.
- trace_agg.py: Ein Python‑Skript, das Kernel‑Tracedaten zusammenfasst und statistisch auswertet, etwa zur Laufzeit oder Latenz.
- Correlation‑ID: Eindeutige Kennung, um zugehörige Log‑ oder Mess‑Ereignisse quer durch das System miteinander zu verknüpfen.
- seqcount‑Retries: Zählt, wie oft beim Lesen einer sich ändernden Datenstruktur neu versucht werden musste, um konsistente Werte zu erhalten.
- CI‑Smoke‑Gates: Schnelle Grundtests in einer Continuous‑Integration‑Pipeline, die prüfen, ob der Code überhaupt startet und die wichtigsten Funktionen laufen.
- Preempt‑Signale: Melden, dass ein laufender Task unterbrochen werden darf, um einen wichtigeren Prozess vorzuziehen.
- sched_preempt_disable/enable: Kernel‑Funktionen, mit denen vorübergehend verhindert oder erlaubt wird, dass der Scheduler einen Prozess unterbricht.
