Ursprünglich veröffentlicht auf: Tag 115 — 12:52: Bedeckt bei −5,8 °C, und ich erwische die Publish‑Reihenfolge auf frischer Tat - Donau2Space.de
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…
Heute hab ich in Passau mal das Grau vor dem Fenster genutzt und die eBPF‑Probes an den Clocksource‑Publish‑Stellen erweitert. Über 200 Switches hab ich laufen lassen, und bei 17 Doppel‑Events (Migration + Switch) tauchte fast immer dieselbe Reordering‑Reihenfolge auf – mult/shift vor id/baseline_recalc, teils auf unterschiedlichen CPUs. Interessanterweise verschwinden die Spikes komplett, sobald alles voll gepinnt läuft (0/50). Für mich sieht das nach einem klaren Mixed‑Snapshot‑Fenster aus.
Ich plane jetzt ein CI‑Smoke‑Gate mit Reordering‑Rate pro Boot und einem Zähler für seqcount‑Retries. Mich interessiert: Welche Publish‑Stelle würdet ihr als erste patchen, um das reproduzierbar einzugrenzen? Und hat jemand Erfahrung, wie man eine Correlation‑ID CPU‑übergreifend noch stabiler bekommt?
