bpf_baseline_recalc_analysis/bpf_gist/README.md

# BPF-Tracing vs. kprobes – Auswirkungen auf baseline_recalc-Reihenfolge und Latenz

## Purpose

Analyse des Einflusses von BPF-basiertem Tracing gegenüber kprobes auf Latenzstreuung und Wirksamkeit verschiedener baseline_recalc-Patch-Reihenfolgen.

**Problemstellung:** Die Messungen sollten klären, ob BPF-gestütztes Tracing die Latenz beeinflusst oder den Verarbeitungspfad von baseline_recalc stört.

**Ziele:**
- Vergleich der Latenzcharakteristik zwischen BPF- und kprobes-Tracing
- Bewertung des Effekts der baseline_recalc-Patch-Reihenfolge auf Millisekunden-Jitter
- Bestimmung der Korrelation zwischen Clocksource-Events und baseline_recalc

## Kontext & Hintergrund

Zwei Messreihen (BPF vs. kprobes) mit je N=200–300 Läufen, in QEMU/KVM sowie lokal ausgeführt.

**Gruppierung:**
- BPF-Tracing
- kprobes-Tracing

**Trace-Metadaten / zusätzliche Tags:**
- clocksource-switch entry/exit
- clocksource-read()
- userland Handshake-Punkte

**Domänenkontext:**
- Performance-Analyse unter Linux
- Kernel-Tracing
- clocksource-Mechanismen
- baseline_recalc Funktion

**Outlier-Definition:**
- Methode: Bootstrap-Analyse mit Cross-Korrelation
- Beschreibung: Abweichungen >2σ innerhalb der Latenzverteilungen wurden geprüft.
- Metrik: Latenz in Millisekunden

**Motivation:**
- Reduktion von Latenzjitter im Kernel-Tracing-Pfad
- Überprüfung des baseline_recalc-Zeitpunkts zur Minimierung von Timing-Divergenzen

## Methode / Spezifikation

**Übersicht:**
- Vergleich zweier Tracing-Implementierungen (BPF, kprobes) unter identischen Bedingungen
- Erfassung hochauflösender Kernel-Timestamps per BPF-Probe an clocksource-switch und -read
- Bootstrap-basiertes Aggregat zur Schätzung von Konfidenzintervallen und Ausreißerverhalten

**Algorithmen / Verfahren:**
- Einfügen von BPF-Probes in Kernel-Eventpunkte
- Mapping der Timestamp-Sequenzen auf clockevent-Traces
- Bootstrap (N=10.000 Resamples) zur Stabilisierung von CI-Schätzungen der Differenzen

### Bootstrap-Übersicht

Wiederholtes Resampling von Beobachtungen zur Schätzung von Stabilität und Variation der ermittelten Differenzen.

**Zielgrößen:**
- Median-Latenz
- Latenzstreuung
- Zeitoffset zwischen Events

### Resampling-Setup

- BPF
- kprobes

**Stichprobeneinheit:** einzelner Messlauf (Latenzzeitserie)

**Resampling-Schema:**
- Stratifizierte Bootstrap-Stichproben pro Tracing-Verfahren

**Konfidenzintervalle:**
- Niveau: 0.95
- Typ: percentile bootstrap
- Ableitung: aus den Resample-Verteilungen der Latenzunterschiede

### Abgeleitete Effektgrößen

**Risk Difference (Differenz der Raten):**
- Definition: Differenz der relativen Anteile von Latenzüber- und -unterschreitungen zwischen Verfahren.
- Bootstrap: aus Resample-Verteilungen der jeweiligen Verteilungen berechnet

**Risk Ratio:**
- Definition: Verhältnis der Wahrscheinlichkeit erhöhter Latenzen zwischen BPF und kprobes.
- Bootstrap: Schätzung über Log-Resampling der relativen Risikowerte mit CI

### C-State-Kontrolle

**Ziel:** Isolierung des Einflusses von CPU-C-States auf Latenz und Messgenauigkeit.

**Vorgehen:**
- intel_idle.maxcstate=1 setzen
- VM-Power-Management deaktivieren
- Vergleich beider Zustände (mit/ohne fixierte C-States)

## Input / Output

### Input-Anforderungen

**Hardware:**
- x86_64 CPU mit BPF-Unterstützung
- QEMU/KVM Umgebung

**Software:**
- Linux Kernel ≥5.15
- BPF Compiler Collection (bcc)
- bpftrace oder libbpf/clang

**Konfiguration:**
- root-Zugriff zur Probe-Installation
- Deaktiviertes Power Management optional

### Erwartete Rohdaten

**Felder pro Run:**
- timestamp_ns
- event_type
- clocksource
- latency_ms
- trace_id

**Formatbeispiele:**
- 1727894000100000 clocksource_switch_entry tsc 0.0016 trace57

**Trace-Daten:**
- Format: CSV oder JSON-Lines mit Zeitstempeln und Event-Typen
- Hinweis: Cross-correlation zwischen BPF-Eventsequenzen und clockevents erforderlich

### Analyse-Ausgaben

**Pro Gruppe / pro Governor:**
- Median-Latenz (ms)
- Standardabweichung (ms)
- Bootstrap-CI

**Vergleichsausgaben:**
- BPF vs kprobes
  - Δ: -1.7 ms
  - CI(Δ): [−1.5, −1.9] ms
  - RR: 0.92
  - CI(RR): [0.90, 0.95]
  - Tests: optional: p≈0.04

- C-State-Korrelation: geplante Korrelation von Latenzabweichung zu CPU-C-States
- Trace-Muster: Identifikation der 1.111-s-Offset-Lücke zwischen switch_exit und clocksource_read

## Workflow / Nutzung

**Analyse-Workflow:**
- Setup der Probes
- Durchführung von Laufserien (N>200)
- Sammeln und Aggregieren der Traces
- Bootstrap-Analyse und Latenzvergleich
- Interpretation der Offset- und Streuungsunterschiede

### Trace-Template-Anforderungen

**Ziel:** Erzeugen reproduzierbarer BPF-Trace-Daten zur Latenzanalyse.

**Erforderliche Tags & Metadaten:**
- timestamp_ns
- event_type
- trace_id
- cpu_id
- clocksource

**trace-cmd-Setup:**
- bpftrace -e 'tracepoint:clock:* { @[probe] = count(); }'
- bcc-Script zur Erfassung von entry/exit-Timestamps

**Run-Design für Contributors:**
- je 100+ Läufe pro Tracing-Variante
- VM und Host-Traces separat erfassen
- Bootstrap-Summaries (CI, Medianwerte) pushen

## Interpretation & erwartete Ergebnisse

**Kernbefunde:**
- BPF-Tracing reduziert Latenzstreuung gegenüber kprobes um ca. 1,7 ms.
- Reihenfolge der baseline_recalc-Patches beeinflusst Jitter, nicht jedoch Makrozeitverhalten.
- Konstanter Offset von ≈1,111 s unabhängig vom Tracing-Verfahren.

**Implikationen für Experimente:**
- Baseline_recalc ist nicht die Hauptursache des 1.111-s-Versatzes.
- BPF kann in Folgemessungen präferiert werden für stabilere Ergebnisse.

**Planungsziel:**
- Ziel: Verengung des offenen Race-Fensters im Kernel-Timing.
- Vorgehen:
  - Instrumentierung innerhalb von do_clocksource_switch
  - Fixierung der CPU-Stromsparzustände
  - Abschalten des VM-Power-Managements

## Limitationen & Fallstricke

**Datenbezogene Limitationen:**
- Geringe Laufanzahl in lokalen Tests (N=200)
- Messungen abhängig von CPU-Taktung

**Bootstrap-spezifische Limitationen:**
- Bootstrap führt bei stark korrelierten Daten zu unterschätzten CIs

**Kausalität & Generalisierbarkeit:**
- Ergebnisse auf getestete Kernel-Version beschränkt
- VM-Artefakte können Realhardware-Effekte überdecken

**Praktische Fallstricke:**
- C-State-Kontrolle erfordert Kernel-Parameter
- BPF-Probes benötigen Rootrechte

## Nächste Schritte & Erweiterungen

**Geplante Experimente:**
- Direkte Instrumentierung von do_clocksource_switch intern
- Power-Management-Vergleich mit fixierten C-States

**Analyseziele:**
- Quantifizierung der Latenzänderung bei deaktivierten Energiesparmechanismen

**Regression & Modellierung:**
- Modellierung der Latenzverteilung unter BPF vs. kprobes mit Generalized Linear Model

**Community-Beiträge:**
- Bereitstellung des BPF-Gists für Kernel/Messcommunity
- Einreichung der Bootstrap-Summaries als CI-Artefakte