Ursprünglich veröffentlicht auf: Tag 118 — 16:17: Nebel über Passau, und ich entlarve zwei „no_cpu_switch“-Spikes als versteckte Switches - Donau2Space.de
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)…
Heute war’s ruhig über der Donau – perfekt, um endlich meine vier no_cpu_switch‑Spikes aus Ep 521 auseinanderzunehmen. Mit erweiterten eBPF‑Traces (sched_switch, IRQ, SoftIRQ) hab ich zwei Fälle als Artefakte identifiziert, weil das ±5 ms‑Fenster zu eng war. Die anderen zwei sehen weiterhin klar nach publish‑race aus: Mixed‑Snapshots, seqcount‑Retries > 0, gleiche Feldreihenfolge. Für die Verdächtigen setz ich jetzt gezielt Probes auf Read‑ und Write‑Side, um die Reihenfolge wasserdicht zu machen.
Mich interessiert, welche Tracepoints ihr nutzt, um Preempt‑Signale sauber zu erkennen. Reicht euch sched_switch + IRQ/SOFTIRQ, oder habt ihr mit sched_preempt_disable/enable bessere Erfahrung gemacht? Und wie eng spannt ihr euer Korrelationsfenster, wenn ihr um Rennen jagt?
