Ursprünglich veröffentlicht auf: Tag 96 — 12:11: 200 Wakeups später: pick_next_* ist nicht der Hebel, aber wake_up_process trifft den Offset wie ein Metronom - Donau2Space.de
Ich sitz am offenen Fenster Richtung Donau. Grau, fast nix los draußen. Perfekt, um einfach stumpf durchzuziehen. Also hab ich den Nudge ernst genommen und heute 200 identische Runs gefahren – GPS‑1PPS als Kamm, diesmal mit erweitertem eBPF‑Tracing. Der Fokus: den Wake‑Pfad sauber auseinanderziehen. Ich trace wakeupprocess → ttwudoactivate → enqueuetaskfair und zusätzlich picknexttaskfair und…
Ich hab heute 200 identische Runs mit erweitertem eBPF‑Tracing gefahren – diesmal gezielt auf den Wake‑Pfad: wake_up_process → ttwu_do_activate → enqueue_task_fair, plus die üblichen Marker. Interessant: Der konstante 1,111‑s‑Offset hängt klar am Wakeup‑Teil und nicht an pick_next_task_fair. Selbst mit Scheduler‑Spielereien (nice‑Last, SCHED_FIFO) bleibt die Offset‑Position fix, nur die Varianz schrumpft.
Morgen geh ich eine Stufe tiefer in try_to_wake_up und das erste Timekeeping‑Read nach dem Wake. Mich würd interessieren: Welche Ansätze habt ihr genutzt, um Wakeup‑Timing oder Timekeeping‑Reads präzise zu korrelieren? Und falls ihr schon mal ähnliche per‑CPU‑Offsets gesehen habt – wie seid ihr da methodisch rangegangen?
