# Phase 53: RSS Tax Triage（33MB vs 2MB の原因切り分け）

目的: Phase 51 で確定した「hakmem の peak RSS ≈33MB」が、(A) ベンチの warmup/prefault 由来なのか、(B) allocator の設計（superslab/metadata 常駐）由来なのかを切り分ける。

ゴール:
- “減らせる RSS” と “速度のために保持する RSS” を分離し、方針（profile）を決める

---

## Step 0: ベース確認（Phase 51 と同条件）

```bash
make bench_random_mixed_hakmem_minimal
BENCH_BIN=./bench_random_mixed_hakmem_minimal \
  DURATION_SEC=300 EPOCH_SEC=5 WS=400 \
  scripts/soak_mixed_single_process.sh > soak_single_hakmem_fast_5m.csv
```

---

## Step 1: prefault の影響（最重要）

bench は `HAKMEM_BENCH_PREFAULT` が未設定だと “cycles/10” を warmup に使う。  
single-process soak は `cycles` が大きいため、prefault が RSS を押し上げる可能性がある。

### 1-A) prefault OFF

```bash
HAKMEM_BENCH_PREFAULT=0 \
  BENCH_BIN=./bench_random_mixed_hakmem_minimal \
  DURATION_SEC=300 EPOCH_SEC=5 WS=400 \
  scripts/soak_mixed_single_process.sh > soak_single_hakmem_fast_5m_prefault0.csv
```

### 1-B) prefault ON（小さく固定）

```bash
HAKMEM_BENCH_PREFAULT=20000000 \
  BENCH_BIN=./bench_random_mixed_hakmem_minimal \
  DURATION_SEC=300 EPOCH_SEC=5 WS=400 \
  scripts/soak_mixed_single_process.sh > soak_single_hakmem_fast_5m_prefault20m.csv
```

判定:
- RSS が大きく下がるなら “ベンチ由来の tax” が主因
- RSS がほぼ変わらないなら “allocator 設計由来（metadata/segment 常駐）” が主因

---

## Step 2: 内部メモリ統計（OBSERVE build）

目的: “どの箱がメモリを握っているか” を観測する（速度は見ない）。

```bash
make bench_random_mixed_hakmem_observe
HAKMEM_TINY_MEM_DUMP=1 HAKMEM_SS_STATS_DUMP=1 HAKMEM_WARM_POOL_STATS=1 \
  ./bench_random_mixed_hakmem_observe 20000000 400 1
```

観測:
- Tiny mem stats / superslab stats / warm pool stats の内訳

---

## Step 3: 方針（profile）

分岐:
- **Speed-first**: RSS は許容（syscall を増やさない、長時間安定性優先）
- **Memory-lean**: RSS を落とす代わりに throughput/ syscalls を受け入れる（将来 Phase 54 で profile 化）

SSOT:
- `docs/analysis/PERFORMANCE_TARGETS_SCORECARD.md` に “peak RSS tax（Mixed/WS=400）” と方針を明記