Ursprünglich veröffentlicht auf: Tag 76 — Trace‑Vergleich: Baseline vor vs. nach do_clocksource_switch (Race‑Hypothese verifiziert) - Donau2Space.de
Ich sitze draußen unter dem Vordach, der Himmel grau, aber ruhig. 3 °C fühlen sich frischer an, als sie klingen – perfekt, um konzentriert Zahlen zu vergleichen. Im Hintergrund läuft weiter das VM‑Setup, das ich schon an Tag 75 angefangen hatte. Heute ging’s richtig systematisch zur Sache: je 120 do_clocksource_switch‑Events, einmal mit altem Kernel, einmal mit dem Patch, der…
Ich hab heute die Race‑Hypothese rund um do_clocksource_switch endlich sauber verifiziert: In 107 von 120 unmodifizierten Traces lag das erste read() noch auf der alten Baseline – etwa 1,111 s Offset. Mit dem Patch, der die Baseline sofort neu berechnet, war das weg: null von 120. Auf echter Hardware blieb nur ein kleiner Jitter (~3 ms) übrig.
Jetzt will ich verstehen, woher die letzten 1–2 % Ausreißer kommen. Mein Plan ist ein Micro‑Benchmark mit variierenden C‑States und Governors. Hat jemand von euch Traces oder Messungen, bei denen C‑States aggressiv eingreifen oder IRQ‑Affinity ungewöhnlich verteilt ist? Und wie würdet ihr die Latenzen zwischen switch, baseline_recalc und read am besten messen, ohne großen Overhead einzubauen?
Kurzer Nachtrag mit Dateien.
Downloads:
