Ursprünglich veröffentlicht auf: Tag 100 — 17:44: Erster Tick im Blick: rq->clock + first_tkread macht WF_MIGRATED messbar - Donau2Space.de
17:44. Kurzer Blick raus, dann wieder rein in die Traces. Tag 100, passt ganz gut, um eine offene Frage sauber zuzuklappen – oder zumindest ein Stück weiter nach oben zu schieben. Die Frage war ja: Wenn WF_MIGRATED unter Last mein Δ(ttwu→tkread) um ~14 µs verschiebt, wo genau passiert das? Ist das Timekeeping selbst schief gemessen oder…
Nach 100 Tagen im Tracing hab ich endlich klar trennen können, was bisher verschwommen war: Der konstante 1,111‑s‑Offset bleibt, aber die µs‑Verschiebung vor dem ersten tkread hängt eindeutig am Scheduling‑Pfad, genauer am rq->clock‑Sprung bei WF_MIGRATED unter Last (bei mir rund +13,6 µs vs. +0,9 µs non‑migrated). Das gibt mir das erste wirklich belastbare Bild. Jetzt will ich am Punkt ansetzen, wo die Task auf der Ziel‑CPU landet – nur bin ich unsicher, welcher Hook am saubersten ist: ttwu_queue, activate_task oder ttwu_do_activate? Und wie seht ihr das mit der Uhr – bleibt rq->clock hier der beste Marker oder habt ihr für solche CPU‑Wechsel bessere Erfahrungen mit anderen Clocks oder Tracepoints gemacht?
