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 contextswitch. Dazu meine bisherigen Marker (scheduler_wake, erster clocksource->read). In trace_agg.py ist dafür ein neues Segment gelandet: wakechain. Pro Run ein Delta‑Histogramm (µs‑Buckets), zeitlich gegen den PPS‑Kamm ausgerichtet.
Messung → Erkenntnis
Das Ergebnis ist überraschend klar. Der konstante ≈1,111‑s‑Offset korreliert weiterhin 1:1 mit schedulerwake / wakeup_process. Kammgenauigkeit. Nicht mit pick_next_task_fair.
Warum ich mir da so sicher bin:
- Über alle 200 Runs ist Δ(wakeupprocess → scheduler_wake) eng gebündelt, kaum Varianz.
- Die Offset‑Marke liegt immer unmittelbar nach wakeupprocess / ttwudoactivate.
- Δ(picknexttaskfair → contextswitch) schwankt stark (je nach Last), ohne dass sich der 1,111‑s‑Wert mitverschiebt.
Das ist für mich ein sauberer Ausschluss: Die Task‑Auswahl (picknext*) triggert den Offset sehr wahrscheinlich nicht. Der Hebel sitzt früher im Wakeup/Activation‑Pfad – oder an etwas, das zeitlich fest an wake_up_process gekoppelt ist. Mein Bauchgefühl (und die Daten): der Moment, wann nach dem Wake der erste relevante Timekeeping‑Read/Update passiert.
Kleines Extra (Scheduler‑Spielerei)
Ich hab noch 40 Zusatzruns drangehängt und gezielt am Scheduler gedreht: einmal die nice‑Last des Mess‑Threads variiert und einmal SCHED_FIFO (das war ja gestern schon Thema).
Ergebnis: Die picknext*‑Zeiten ändern sich deutlich, wie erwartet. Die Offset‑Position bleibt fest. Einziger Effekt: Bei FIFO wird die Varianz der Wake‑Deltas kleiner. Heißt: deterministischer Ablauf, aber derselbe Offset. Fei logisch im Nachhinein.
Was bleibt offen → nächster Schritt
Der Faden von gestern ist damit nicht tot, aber enger: picknext* ist nicht der Hebel. Vorerst rund.
Morgen instrumentiere ich eine Stufe davor und danach im Timekeeping‑Pfad – getriggert vom Wakeup:
- eBPF‑Probes auf trytowakeup / ttwudo_wakeup
- direktes Logging des ersten Timekeeping‑Reads im jeweiligen Kontext (Stack‑ID, CPU‑ID)
Hypothese: Das vermeintliche „Race vor dem ersten read“ ist in Wahrheit ein Wakeup‑Kontext‑Problem (per‑CPU‑Baseline, Seqcount, Clocksource‑State). Wenn das stimmt, sollte man den Offset exakt dort festnageln können.
Parallel starte ich einen Mehrsystem‑Plan (N≈250 pro Maschine, identisches Script). Dann seh ich endlich, ob dieses wake‑gebundene Muster hardwareübergreifend gleich bleibt.
Jetzt speicher ich die Plots weg und lass den Kopf kurz runterkühlen. Pack ma’s morgen weiter an. 🚀
Diagramme
Begriffe kurz erklärt
- GPS-1PPS: Ein GPS-1PPS-Signal liefert jede Sekunde einen präzisen elektrischen Impuls, der zur Zeit- und Frequenzmessung genutzt wird.
- eBPF-Tracing: Mit eBPF-Tracing kann man im Linux-Kernel Abläufe in Echtzeit beobachten, ohne das System stark zu verlangsamen.
- wake_up_process: Die Funktion wake_up_process weckt einen schlafenden Prozess, damit dieser weiterarbeiten kann.
- ttwu_do_activate: ttwu_do_activate bereitet einen Prozess darauf vor, vom Scheduler aktiviert und auf die CPU gesetzt zu werden.
- enqueue_task_fair: enqueue_task_fair fügt eine Aufgabe in die Warteschlange des fairen Linux-Schedulers ein.
- pick_next_task_fair: pick_next_task_fair wählt die nächste faire Aufgabe aus, die vom Prozessor ausgeführt werden soll.
- context_switch: Bei einem context_switch wechselt das Betriebssystem von einem laufenden Prozess zu einem anderen und speichert dabei deren Zustände.
- scheduler_wake: scheduler_wake markiert Aufgaben als bereit, damit sie vom Scheduler wieder ausgeführt werden können.
- trace_agg.py: trace_agg.py ist meist ein Python-Skript, das Tracedaten sammelt und für spätere Analyse zusammenfasst.
- SCHED_FIFO: SCHED_FIFO ist ein Linux-Echtzeit-Scheduling-Modus, bei dem Prozesse strikt nach Reihenfolge ohne Zeitverteilung laufen.
- eBPF-Probes: eBPF-Probes sind kleine Messpunkte im Kernel, die Daten für Tracing und Analyse sammeln.
- try_to_wake_up: try_to_wake_up versucht, einen schlafenden Prozess in den Zustand „bereit zum Ausführen“ zu versetzen.
- Seqcount: Seqcount ist ein Mechanismus, um gleichzeitig gelesene Daten ohne Sperren konsistent zu halten.
- Clocksource-State: Der Clocksource-State beschreibt den aktuellen Zustand oder die Zuverlässigkeit der Systemzeitquelle im Kernel.
