Files
hakmem/docs/status/archive/PHASE_6.19_PLAN_2025_10_23.md

35 lines
1.7 KiB
Markdown
Raw Normal View History

# Phase 6.19 Plan (2025-10-23)
目的: Large 帯 (64KB1MB, 4T) の l25_get/hak_alloc のホットコストを半減し、mimalloc に接近。
現状要約10s, 4T, timing ON
- Mid: hakmem ≈ 9.9M ops/s, ロック/シスコール支配ではない
- Large: hakmem ≈ 0.10M ops/s → l25_get 3965%, hak_alloc 2038%, syscalls ≈ 38%
- Big: BGバッチ動作OK、無効freeログは既定OFFが望ましい
問題点(根本)
- データプレーンと制御プレーンの未分離: 中央でブロック単位を扱い過ぎ、ヘッダ書込みが残存
- シャード偏り: site→shard の偏りが try→再探査を誘発
- 順序固定の不足: TLSミス時の ActiveRun/Remote/Central の順が最適化されていない
P0: ホットパス最短化
1) L2.5: 中央は run 専用ブロックfree-listを廃止/非推奨化)
2) L2.5: bump-run + ActiveRun を既定化TLS直詰め、ブロック連結なし
3) L2.5: Remote drain 優先nonempty O(1) 選択 + trylock ≤ 23
4) L2.5: シャードハッシュsplitmix64既定ON
5) ログ抑制: `HAKMEM_INVALID_FREE_LOG=0` 既定
P1: 書込み削減/ラン長最適化
1) L2.5: ヘッダライト/ヘッダレス(ページ記述子)に段階移行
2) ラン長 A/B64/32/16/8 …)で mmap 回数削減
3) RING_CAP / TLS_LO_MAX の再探索4Tでの枯渇・吐き戻し最小化
計測手順10秒, timing
- Large 4T: `HAKMEM_TIMING=1 HAKMEM_WRAP_L25=1 HAKMEM_TRYLOCK_PROBES=8 HAKMEM_TLS_LO_MAX=512`
- A/B: `HAKMEM_L25_PREF=remote|run`, `HAKMEM_L25_RUN_BLOCKS=N`, `HAKMEM_SHARD_MIX=0/1`
期待効果
- l25_get の avg cycles を 3050% 減
- mmap の発生密度低下(ラン長倍化)