8f18963ad5
- Redefine TinyHotHeap v2 as per-thread Hot Box with clear boundaries - Add comprehensive OS statistics tracking for SS allocations - Implement route-based free handling for TinyHeap v2 - Add C6/C7 debugging and statistics improvements - Update documentation with implementation guidelines and analysis - Add new box headers for stats, routing, and front-end management
3.4 KiB
3.4 KiB
MID/Large CPU Hotpath (Phase54)
- 条件:
./bench_mid_large_mt_hakmem 1 1000000 400 1(Release)
HAKMEM_TINY_HEAP_PROFILE=C7_SAFE,HAKMEM_TINY_C7_HOT=1,HAKMEM_TINY_HOTHEAP_V2=0,HAKMEM_TINY_LARSON_FIX=1 - スループット: HAKMEM ≈28.1M ops/s（mimalloc 54.2M / system 15.3M は Phase53 より）
- perf stat (cycles:u): IPC≈2.4、page-faults≈7.4k（Phase53 と同等）
cycles:u ホットシンボル（self%）
- hak_pool_try_alloc.part.0 … 14.7% （pool alloc ホットパス）
- worker_run … 9.2% （ドライバ側のループと malloc 呼び出しを含む）
- free / hak_free_at.constprop.0 … ~9–10%（glibc free 連携＋自前 free）
- __memset_avx2_unaligned_erms … ~9%（pool 初期化/clear と推定）
- mid_desc_lookup … 3.8%
- hak_super_lookup … 1.4%
- hak_pool_free.part.0 … 0.7%
所感
- pool 系（hak_pool_try_alloc / hak_pool_free）と free/memset が支配的で、mid_desc_lookup と super_lookup も目立つ。
- kernel 枠の大きな inclusive% は free/memset 配下にぶら下がっており、userland 側の pool/front の命令数削減が効果的そう。
Phase55 方針（pool allocator ホットパス軽量化）
- スコープ: core/hakmem_pool.c / core/hakmem_smallmid.c / core/box/pool_* の pool fast path。
- hak_pool_try_alloc を直線化:
- 「TLS/local freelist hitなら即 return」を先頭に寄せ、debug/統計/slow は unlikely 側へ。
- mid_desc_lookup/クラス情報は入口で 1 回だけ計算し、TLS へのキャッシュを検討。
- hak_pool_free / hak_free_at:
- self-thread free は pool push を最優先にし、cross-thread/debug は unlikely に寄せる。
- free 時の memset/初期化が不要なケースを洗い出し、スキップ余地をメモ。
- mid_desc_lookup のキャッシュ:
- size→class→desc を入口で 1 回だけ決める仕組み（既存キャッシュの再利用も含め）を検討。
- 成功ライン（bench_mid_large_mt_hakmem 1 1000000 400 1, Release):
- ops/s を 28–29M → 30–32M（+5〜10%）へ。
- perf report で hak_pool_try_alloc + free 周辺 self% が数ポイント低下。
Phase56 結果（pool fast path 初期実装）
- 変更: PoolBlock→user 変換をヘルパに寄せ、TLS ring/lo pop と self-thread free push を直線化。owner 判定は mid_desc の 1 回 lookup で共有。
- ベンチ（C6-heavy, ws=256, iters=20k, C7_SAFE, v2 OFF）: 25.9M ops/s（目標 30–32M に届かず、前回 28–29M から回帰）。
- perf stat（同条件 1M/400）: cycles=225,766,496、instructions=528,335,613、task-clock=57.88ms、ops/s≈25.7M。
- 所感: fast-path整理だけでは効果薄く、むしろ低下。pool 内の memset/desc まわりやリング補充順序をより大胆に削らないと改善しない。次のステップとして追加の枝削減・キャッシュ導入を検討。
Phase57 回帰トリアージ（pool v2 をゲート化）
- 変更:
HAKMEM_POOL_V2_ENABLEDを追加し、v1/v2 の pool 実装を env で切替。細分スイッチとしてHAKMEM_POOL_V2_BLOCK_TO_USER/HAKMEM_POOL_V2_TLS_FAST_PATHを用意（デフォルト ON, v2 時のみ有効）。 - ベンチ（C6-heavy, 1M/400, Release）:
- v1 (POOL_V2_ENABLED=0): 27.40M ops/s
- v2 (POOL_V2_ENABLED=1): 24.73M ops/s
- 所感: v2 の変更が回帰要因と判明。標準は v1 に戻し、スイッチ単位の A/B でどの改変が悪いかを切り分ける方針。