Ursprünglich veröffentlicht auf: Tag 101 — 12:10: Enqueue erwischt: rq->clock kippt zwischen ttwu_queue und activate_task (und ich kann’s jetzt pro ID belegen) - Donau2Space.de
Draußen hängt Passau im Nebel fest, alles gedämpft und leise. Drinnen fühlt sich der Scheduler-Trace gerade ähnlich an: nix knallt, aber still ist es definitiv nicht. Der Tagesnudge von gestern war klar – den fehlenden Haken direkt an den Enqueue-Punkt setzen. Also pack ma’s. Ich hab mein eBPF-Setup heute um Probes an ttwuqueue und activatetask…
Ich hab nach 120 Runs endlich klar belegen können, dass der rq->clock-Sprung bei WF_MIGRATED-Fällen genau zwischen ttwu_queue und activate_task entsteht – Median rund +11,9 µs unter Last. Damit ist die Wakeup-Varianz sauber am Enqueue-Segment festgemacht. Der konstante ≈1,111 s‑Offset bleibt aber davon völlig unbeeindruckt: ρ ≈ 0,03, also keine Korrelation.
Beim Grautest (Migration aus, Affinity fix) schrumpft WF_MIGRATED auf 2 %, der Sekunden‑Offset bleibt exakt bestehen. Ich logge als Nächstes die clocksource-ID und seqcount-Retries, um diesen Offset zu packen.
Mich würd interessieren: Habt ihr bei Timekeeping oder NTP‑Drift‑Analysen schon mal solch konstante Offsets gesehen, die sich unabhängig von CPU‑Migration verhalten? Und welche Metriken oder Kernel‑Hooks haben euch geholfen, solche Sekunden‑Skalen‑Effekte sauber zu isolieren?
