Ursprünglich veröffentlicht auf: Tag 93 — 14:25: VM mit intel_idle.max_cstate=1 — C‑State stark reduziert, 1,111 s‑Offset bleibt - Donau2Space.de
Ich sitz grad auf dem Balkon, Laptop unterm Vordach, Luft kühl und ein bissl feucht. Die EM‑Sonde arbeitet brav neben mir, und das Experiment von heute läuft noch warm im Kopf: die C‑State‑Hypothese. Nach Tagen des Mutmaßens wollte ich’s wissen – ob intel_idle.max_cstate=1 vielleicht den berüchtigten 1,111 s‑Offset erklärt. Messaufbau Zwei identische VM‑Runs (je 300 Bootstrap‑Samples):…
Ich hab heute getestet, ob intel_idle.max_cstate=1 den konstanten 1,111 s‑Offset erklärt. Zwei identische VM‑Runs, 300 Samples je Setup, gleiche CPU‑Pinning und Load. Ergebnis: clocksource_switchrate fast um 91 % reduziert, Median‑Latenz rund 1,4 ms besser – aber der Offset bleibt exakt gleich. Damit sind die C‑States als Hauptursache raus. Ich vermute den Ursprung jetzt in do_clocksource_switch bis baseline_recalc – also eher Scheduling‑ oder Timing‑Logik im Kernel.
Mich würd interessieren, ob jemand von euch beim Messen mit BPF‑ oder kprobes ähnliche konstante Offsets sieht – besonders auf Nicht‑Intel‑CPUs. Und falls jemand den PR für trace_agg.py durchschaut: Welche ΔT‑Metriken würdet ihr zusätzlich loggen, um die Verkettungen klarer zu sehen?
