| .. | ||
| README.md | ||
Probe-Konfiguration für Read-/Write-Sides zur Präzisierung von no_cpu_switch-Analysen
Purpose
Dokumentation der erweiterten eBPF-Probing-Strategie zur Erkennung und Klassifikation von no_cpu_switch-Spikes.
Problemstellung: Unklare Ursachen für no_cpu_switch-Spikes erfordern differenzierte Erfassung von Kontextwechseln und seqcount-Aktivität.
Ziele:
- Erweiterung der Messung um Kontext-Marker für Scheduler- und Interrupt-Ereignisse
- Unterscheidung echter publish-race-Vorkommen von Messartefakten
- Zielgerichtete Platzierung neuer Read-/Write-Probes zur zeitlichen Präzisierung
Kontext & Hintergrund
Trace-Daten aus Ep-521 mit identifizierten no_cpu_switch-Spikes (case01–case04).
Gruppierung:
- case_01
- case_02
- case_03
- case_04
Trace-Metadaten / zusätzliche Tags:
- Correlation-ID zur Zusammenführung von Eventdaten
- CPU-ID-Erfassung pro Ereignisfenster
Domänenkontext:
- Scheduling und Interrupt Handling im Linux-Kernel
- eBPF-Tracing von Kernel-Events via sched und irq-Tracepoints
Outlier-Definition:
- Methode: Kontextbasierte Klassifikation
- Beschreibung: Abweichende Events ohne sched_switch oder IRQ-Aktivität gelten als publish-race-suspect.
- Metrik: Kombination aus had_sched_switch, had_irq, seqcount_Retries
Motivation:
- Reduktion von Fehldiagnosen durch unzureichende Kontextsignale
- Systematische Ermittlung versteckter CPU-Kontextwechsel
- Ableitung belastbarer Hypothesen für Publish-Race-Erkennung
Methode / Spezifikation
Übersicht:
- Erweiterung des Trace-Setups um eBPF-basierte Marker in festem Zeitfenster (±5ms, ±20ms).
- Aufzeichnung von sched_switch-, irq_handler- und softirq-Ereignissen pro Correlation-ID.
- Automatische Klassifikation anhand einfacher Entscheidungsregel in trace_agg.py.
Algorithmen / Verfahren:
- Definiere event window (±5 ms und ±20 ms).
- Erfasse Events: sched:sched_switch, irq:irq_handler_entry/exit, softirq:softirq_entry/exit.
- Konstruiere JSON-Zusammenfassung pro Correlation-ID: { had_sched_switch, had_irq, had_softirq, cpu_ids_seen[]. }
- Klassifiziere anhand Entscheidungsbaum A/B-Regel.
Bootstrap-Übersicht
Kein statistisches Resampling – deterministische Zuordnung der Eventklassen.
Zielgrößen:
- Hidden-Switch-Erkennung
- Publish-Race-Verdachtsklassifikation
C-State-Kontrolle
Ziel: Erkennung indirekter Scheduler-Kontextwechsel ohne C-State-Wechsel.
Vorgehen:
- Analyse von IRQ- und SoftIRQ-Aktivität als Proxy für verdeckte Kontextwechsel.
- Abgleich sichtbarer CPU-IDs mit erwarteter Ausführungsumgebung.
Input / Output
Input-Anforderungen
Hardware:
- Mehrkernprozessor mit aktiviertem eBPF-Support
Software:
- Linux Kernel ≥ 5.x
- bpftrace oder custom eBPF collector
- Python 3 für trace_agg.py
Konfiguration:
- trace-cmd Setup mit aktivierten sched_* und irq_* Tracepoints
- Zielprozesse mit Correlation-ID versehen
Erwartete Rohdaten
Felder pro Run:
- correlation_id
- had_sched_switch
- had_irq
- had_softirq
- cpu_ids_seen
Formatbeispiele:
- { "had_sched_switch":1, "had_irq":0, "had_softirq":0, "cpu_ids_seen":[2,3] }
Trace-Daten:
- Format: JSON aggregierte Eventdaten pro Correlation-ID
- Hinweis: Ergebnisse nach Fenstergröße getrennt (±5ms, ±20ms)
Analyse-Ausgaben
Pro Gruppe / pro Governor:
- Anteil hidden-switch
- Anteil publish-race-suspect
Vergleichsausgaben:
-
window_5ms vs window_20ms
- Δ: Sensitivitätsdifferenz für sched_switch-Erkennung
-
Trace-Muster: Sequenzanalyse mult→shift→id/baseline_recalc in publish-race-Suspects
Workflow / Nutzung
Analyse-Workflow:
- Starte erweiterten eBPF-Trace mit definierten Tracepoints.
- Führe trace_agg.py zur Aggregation aus.
- Analysiere Event-Zusammenfassungen pro Correlation-ID.
- Klassifiziere Ergebnisse nach Entscheidungsregel.
- Setze gezielte Read-/Write-Probes auf identifizierte publish-race-Suspects.
Trace-Template-Anforderungen
Ziel: Standardisierung der Event-Erfassung für korrelierte Trace-Analysen.
Erforderliche Tags & Metadaten:
- correlation_id
- cpu_id
- timestamp
- event_type
trace-cmd-Setup:
- trace-cmd record -e sched:sched_switch -e irq:irq_handler_entry -e softirq:softirq_entry
- exportiere Rohdaten für trace_agg.py
Interpretation & erwartete Ergebnisse
Kernbefunde:
- case_01–02 zeigen hidden-switch durch Kontextmarker im erweiterten Fenster.
- case_03–04 bleiben clean, aber publish-race-suspect nach seqcount-Retries.
Implikationen für Experimente:
- Fehlende CPU-Wechsel-Signale können durch IRQ-Aktivität kaschiert sein.
- Fensterweitung erhöht Erkennungssensitivität für versteckte Scheduler-Events.
Planungsziel:
- Ziel: Stabilisierung der Klassifikation von no_cpu_switch-Phänomenen.
- Vorgehen:
- Einführung zusätzlicher Read-/Write-Side-Probes zur Feinanalyse.
- Trennung von Race-Verdacht und Scheduler-Artefakten in zukünftigen Runs.
Limitationen & Fallstricke
Datenbezogene Limitationen:
- Fenstergröße beeinflusst Sensitivität und Specificity der Klassifikation.
- Fehlende Preempt-Tracepoints können Kontextwechsel unerkannt lassen.
Kausalität & Generalisierbarkeit:
- Korrelation zwischen Kontextevent und Race-Verdacht nicht kausal belegbar.
- Ergebnisse restriktiv auf getestetes Kernelsetup übertragbar.
Praktische Fallstricke:
- Hohe Ereignisdichte kann Aggregation in trace_agg.py verlangsamen.
- Unscharfe Zeitkorrelationen bei multiplen CPUs möglich.
Nächste Schritte & Erweiterungen
Geplante Experimente:
- Integration von sched_preempt_disable/enable zur Feinkleinmessung von Preempt-Signalen.
Analyseziele:
- Validierung der publish-race-Hypothese durch erweiterte Sequenzanalyse.
Regression & Modellierung:
- Automatische Erkennung von Hidden-Switch-Mustern durch regelbasiertes Scoring.
Community-Beiträge:
- Abstimmung geeigneter Kernel/Tracepoint-Kombinationen für Preempt-Überwachung.