Add bpf_gist/README.md
This commit is contained in:
parent
b48a7dfe6f
commit
0deeef2e80
1 changed files with 226 additions and 0 deletions
226
bpf_gist/README.md
Normal file
226
bpf_gist/README.md
Normal file
|
|
@ -0,0 +1,226 @@
|
||||||
|
# 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
|
||||||
Loading…
Reference in a new issue