Benchmarks, die man nachbauen kann.

DENSITY veröffentlicht Ergebnisse nur mit Methodik + Rohdaten. Kein „Marketing-Benchmark“. Der Fokus im MVP ist RAM-Dichte (KSM).

Minimal: Run + Publish Linux · sudo

sudo densityctl enable
sudo densityctl bench --profile P1 --scale 10..80..10 --mem-mib 256 --out results \
  --publish docs/data/benchmarks.latest.json

# dann commit/push, damit GitHub Pages es lädt

Profile

P1 (identisch): maximaler Merge-Effekt (Proof).
P2 (ähnlich): realistischere Divergenz.
P3 (worst-case): zeigt Grenzen & CPU-Kosten.

Ziel ist nicht „immer schneller“, sondern: mehr Workloads auf gleicher Maschine bei kontrollierten Trade-offs.

Methodik

Metriken

KSM-Stats (pages_shared/pages_sharing), MemAvailable, Alive-Instanzen, und (best-effort) ksmd CPU-Ticks als „Kostenindikator“.

Warmup

KSM braucht Zeit zum Scannen/Mergen. Deshalb gibt es einen Warmup (Default 20s). Kürzer = weniger Merge, länger = mehr Merge (und ggf. mehr CPU).

Fairness

Gleiche Maschine, gleiche Skala, gleiche Warmup-Zeit. Baseline = KSM aus. DENSITY = KSM an (konservativ getunt).

Aktuell veröffentlichte Daten

Diese Tabelle wird automatisch aus docs/data/benchmarks.latest.json geladen. Wenn noch keine Datei vorhanden ist, siehst du nur den Platzhalter.

N	Alive	Saved (MiB)	ksmd ticks Δ	MemAvail vorher (MiB)	MemAvail nachher (MiB)
Noch keine Daten geladen. (siehe Anleitung oben)

Trade-offs / Sicherheit

CPU: KSM scannt und kostet CPU. DENSITY startet konservativ (geringe Scanrate) und misst mit.
Latenz: Bei aggressivem Tuning kann sich das bemerkbar machen – deshalb Bench + Defaults.
Multi-Tenant: Memory-Dedup kann Side-Channel-Risiken erhöhen. Für untrusted Multi-Tenant sollte KSM oft aus bleiben.