no_cpu_switch_analysis/probe_config/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.