Guard madvise ENOMEM and stabilize pool/tiny front v3

This commit is contained in:
Moe Charm (CI)
2025-12-09 21:50:15 +09:00
parent e274d5f6a9
commit a905e0ffdd
45 changed files with 3154 additions and 242 deletions

View File

@ -32,3 +32,53 @@
- pop/empty 内の分岐を整理し、C7 SAFE の理想パスcurrent_page固定に寄せる。
- header write / memset を最小化する実験スイッチを検討。
## C7 v3 ON, Mixed 161024B (ws=400, iters=1,000,000, userland cycles)
環境: `HAKMEM_BENCH_MIN_SIZE=16 HAKMEM_BENCH_MAX_SIZE=1024 HAKMEM_TINY_HEAP_PROFILE=C7_SAFE HAKMEM_TINY_C7_HOT=1 HAKMEM_TINY_HOTHEAP_V2=0 HAKMEM_POOL_V2_ENABLED=0 HAKMEM_SMALL_HEAP_V3_ENABLED=1 HAKMEM_SMALL_HEAP_V3_CLASSES=0x80`
- Throughput: **48.96M ops/s**(前回 v3 ON と同レンジ)
- perf record `cycles:u` (171 samples, release build without symbols):
- 上位は `free` / `malloc` / `main` の無名フレームに潰れてしまい、非C7 Tiny front の細かい関数名が出ず。
- シンボル再取得には DEBUG/記号付きビルドで perf し直す必要あり。
- 所感: C7 v3 以外のホットパス特定には、size→class→route 前段や unified cache hit パスを再シンボル化して見る必要がある。現状のバイナリでは細部が見えない。
## Mixed 161024B (ws=400, iters=1,000,000, userland cycles, C7 v3 ON, DEBUGビルド)
環境: `HAKMEM_BENCH_MIN_SIZE=16 HAKMEM_BENCH_MAX_SIZE=1024 HAKMEM_TINY_HEAP_PROFILE=C7_SAFE HAKMEM_TINY_C7_HOT=1 HAKMEM_TINY_HOTHEAP_V2=0 HAKMEM_POOL_V2_ENABLED=0 HAKMEM_SMALL_HEAP_V3_ENABLED=1 HAKMEM_SMALL_HEAP_V3_CLASSES=0x80`
ビルド: `make clean && CFLAGS='-O2 -g …' USE_LTO=0 OPT_LEVEL=2 NATIVE=0 make bench_random_mixed_hakmem`
- Throughput: **46.146.3M ops/s**(リリース時の ~49M よりやや低いが符号付きビルドで許容)
- perf record `cycles:u -F5000 --call-graph dwarf` (200 samples) の self% 上位C7 v3 以外を抜粋):
- free 23.5%, malloc 18.8%, main 13.7%(ベンチハーネス由来)
- **tiny_region_id_write_header 6.7%**
- **ss_map_lookup 3.6%**
- unified_cache_enabled 2.8%
- tiny_guard_is_enabled 2.2%
- classify_ptr 1.4%size→class 判定系)
- mid_desc_lookup 1.3%
- hak_free_at 0.9%, hak_pool_mid_lookup 0.7%
- so_alloc/so_free 合計 ~7%C7 v3 本体)
- 所感非C7 Tiny front 目線):
- header 書き込みtiny_region_id_write_headerが依然目立つ。
- Superslab 判定前の `ss_map_lookup` が 34% 程度残っている。
- route/guard 判定unified_cache_enabled / tiny_guard_is_enabled / classify_ptrが合わせて ~6% 程度。
- 次は「size→class→route 前段header」をフラット化するターゲットが有力。
### Front v3 snapshot 導入メモ
- `TinyFrontV3Snapshot` を追加し、`unified_cache_on / tiny_guard_on / header_mode` を 1 回だけキャッシュする経路を front v3 ON 時に通すようにした(デフォルト OFF
- Mixed 161024B (ws=400, iters=1M, C7 v3 ON, Tiny/Pool v2 OFF) で挙動変化なしslow=1 維持)。ホットスポットは依然 front 前段 (`tiny_region_id_write_header`, `ss_map_lookup`, guard/route 判定) が中心。
### Front v3 size→class LUT メモPhase2-A 実装済み、A/B これから)
- ENV `HAKMEM_TINY_FRONT_V3_LUT_ENABLED` を追加(デフォルト OFF。front v3 ON 時に size→class→route を Tiny 専用 LUT から 1 ルックアップで取得し、従来の `hak_tiny_size_to_class` + route 読みを代替する。
- LUT は起動時に既存の size→class 変換と route スナップショットをそのまま写経して構築するため挙動は変えない。
- A/B (Mixed 161024B, ws=400, iters=1M, C7 v3 ON, Tiny/Pool v2 OFF, front v3 ON):
- LUT=0: 44.820M ops/s
- LUT=1: 45.231M ops/s+0.9%
- HEAP_STATS は TinyHeap v1 経路外のため出力なし。C7_PAGE_STATS は prepare_calls=2446 で変化なし。
### Header v3 (C7-only) 簡易スキップ実験
- ENV: `HAKMEM_TINY_HEADER_V3_ENABLED` / `HAKMEM_TINY_HEADER_V3_SKIP_C7` を追加。C7 v3 alloc 時だけ tiny_region_id_write_header を通さず 1byte store にする。
- Mixed 161024B (ws=400, iters=1M, front v3 ON, LUT ON, route_fast=0, Tiny/Pool v2 OFF):
- header_v3=0: 44.29M ops/s, C7_PAGE_STATS prepare_calls=2446
- header_v3=1 + SKIP_C7=1: 43.68M ops/s約 -1.4%、prepare_calls=2446、fallback/page_of_fail=0
- 所感: C7 v3 のヘッダ簡略だけでは perf 改善は見えず。free 側のヘッダ依存を落とす or header light/off を別箱で検討する必要あり。