tomoaki/hakmem
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
b01c99f209cf8b0c05500d7ef1c8a04685ca907f
hakmem/docs/analysis/PERF_ANALYSIS_TINY_FRONT_FLATTEN_PHASE42.md
Moe Charm (CI) a905e0ffdd Guard madvise ENOMEM and stabilize pool/tiny front v3
2025-12-09 21:50:15 +09:00

23 KiB
Raw Blame History

Phase42 Front Route Flatten ベースライン計測

  • ビルド: make bench_random_mixed_hakmem -j4

C7-only (ws=64, iters=20000, v2 OFF)

  • ENV: HAKMEM_BENCH_C7_ONLY=1 HAKMEM_TINY_HEAP_PROFILE=C7_SAFE HAKMEM_TINY_HOTHEAP_V2=0 HAKMEM_TINY_STATS_BOX=1 HAKMEM_TINY_STATS_BATCH=0 HAKMEM_TINY_LARSON_FIX=1
  • 結果: Throughput = 41365988 ops/s
  • 備考: HEAP_STATS のダンプは出ず（要調査）。FRONT_CLASS: cls7 alloc=11016。

Mixed 16–1024B (ws=256, iters=20000, v2 OFF)

  • ENV: HAKMEM_BENCH_MIN_SIZE=16 HAKMEM_BENCH_MAX_SIZE=1024 HAKMEM_TINY_HEAP_PROFILE=C7_SAFE HAKMEM_TINY_HOTHEAP_V2=0 HAKMEM_TINY_LARSON_FIX=1 HAKMEM_TINY_FRONT_CLASS_STATS=1
  • 結果: Throughput = 43538552 ops/s
  • 備考: FRONT_CLASS alloc counts（cls2:147, cls3:341, cls4:720, cls5:1420, cls6:2745, cls7:5692）。HEAP_STATS ダンプは出ず。

Tiny-only 8–128B (ws=256, iters=20000, v2 OFF) ※任意測定

  • ENV: HAKMEM_BENCH_MIN_SIZE=8 HAKMEM_BENCH_MAX_SIZE=128 HAKMEM_TINY_HEAP_PROFILE=C7_SAFE HAKMEM_TINY_HOTHEAP_V2=0 HAKMEM_TINY_LARSON_FIX=1 HAKMEM_TINY_FRONT_CLASS_STATS=1
  • 結果: Throughput = 65979164 ops/s
  • 備考: FRONT_CLASS alloc counts（cls2:147, cls3:341, cls4:720, cls5:9857）。HEAP_STATS ダンプは出ず。

Phase65 後半: 長尺 v2 ON/OFF A/B（ws=400, iters=1M, PROFILE=C7_SAFE）

  • 共通 ENV: HAKMEM_TINY_C7_HOT=1 HAKMEM_TINY_LARSON_FIX=1 HAKMEM_TINY_HEAP_STATS=1 HAKMEM_TINY_HEAP_STATS_DUMP=1 HAKMEM_TINY_HOTHEAP_V2_STATS=1

C7-only

  • v2 OFF (HOTHEAP_V2=0): 38.24M ops/s, HEAP_STATS[7] fast=550099 slow=1。
  • v2 ON (HOTHEAP_V2=1, classes=0x80): 38.68M ops/s, HEAP_STATS[7] fast=550099 slow=1。v2 stats: refill=1、fail/fallback=0。

Mixed 16–1024B

  • v2 OFF: 41.78M ops/s, HEAP_STATS[7] fast=283169 slow=1。
  • v2 ON: 41.94M ops/s, HEAP_STATS[7] fast=283169 slow=1。v2 stats: refill=1、fail/fallback=0。
  • 所感: 長尺では v2 ON/OFF とも slow≈1 に収束し、性能も ±5% 以内（むしろ微プラス）。短尺で見える refill≈50 はウォームアップ由来と判断。

Phase65/66 サマリ表（1M / ws=400, PROFILE=C7_SAFE）

プロファイル v2 OFF ops/s v2 ON ops/s HEAP_STATS[7] slow 備考
C7-only (C7-only ベンチ) 38.24M 38.68M 1 v2 は微プラス・refill=1
Mixed 16–1024B 41.78M 41.94M 1 v2 は微プラス・refill=1

Phase43 (HEAP_STATS 再有効化の再計測) ※v2 OFF

  • HEAP_STATS 用 ENV を明示 (HAKMEM_TINY_HEAP_STATS=1 HAKMEM_TINY_HEAP_STATS_DUMP=1) したが、現状はダンプが出ていない。fast/slow の値は別途要確認。

C7-only (ws=64, iters=20000)

  • ENV: HAKMEM_BENCH_C7_ONLY=1 HAKMEM_TINY_HEAP_PROFILE=C7_SAFE HAKMEM_TINY_C7_HOT=1 HAKMEM_TINY_HOTHEAP_V2=0 HAKMEM_TINY_STATS_BOX=1 HAKMEM_TINY_STATS_BATCH=0 HAKMEM_TINY_LARSON_FIX=1 HAKMEM_TINY_HEAP_STATS=1 HAKMEM_TINY_HEAP_STATS_DUMP=1 HAKMEM_TINY_FRONT_CLASS_STATS=1
  • Throughput: 37,777,547 ops/s
  • HEAP_STATS cls7: fast=11015 slow=1 / free_fast_local=8726、C7_PAGE_STATS: prepare_calls=1 prepare_with_current_null=1
  • FRONT_CLASS: cls7 alloc=11016 free=8726

Mixed 16–1024B (ws=256, iters=20000)

  • ENV: 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_TINY_LARSON_FIX=1 HAKMEM_TINY_HEAP_STATS=1 HAKMEM_TINY_HEAP_STATS_DUMP=1 HAKMEM_TINY_FRONT_CLASS_STATS=1
  • Throughput: 42,029,698 ops/s
  • HEAP_STATS cls7: fast=5691 slow=1 / free_fast_local=4573（cls5/6 未出力）
  • FRONT_CLASS alloc: cls2=147 cls3=341 cls4=720 cls5=1420 cls6=2745 cls7=5692

Tiny-only 8–128B (ws=256, iters=20000)

  • ENV: HAKMEM_BENCH_MIN_SIZE=8 HAKMEM_BENCH_MAX_SIZE=128 HAKMEM_TINY_HEAP_PROFILE=C7_SAFE HAKMEM_TINY_C7_HOT=1 HAKMEM_TINY_HOTHEAP_V2=0 HAKMEM_TINY_LARSON_FIX=1 HAKMEM_TINY_HEAP_STATS=1 HAKMEM_TINY_HEAP_STATS_DUMP=1 HAKMEM_TINY_FRONT_CLASS_STATS=1
  • Throughput: 65,890,043 ops/s
  • HEAP_STATS: 出力なし（cls7 も 0）→ クラス0〜6は計測対象外の可能性。要調査。

メモ

  • C7-only では HEAP_STATS/PAGE_STATS が出ることを確認。Mixed/Tiny-only では cls7 以外の HEAP_STATS が落ちておらず、環境/計測対象の条件を再確認する余地あり。

Phase63: C6 v2 A/B（C6-heavy / Mixed, C7 SAFE）

  • 共通 ENV: HAKMEM_TINY_HEAP_PROFILE=C7_SAFE HAKMEM_TINY_C7_HOT=1 HAKMEM_TINY_HOTHEAP_V2_STATS=1 HAKMEM_TINY_HEAP_STATS=1 HAKMEM_TINY_HEAP_STATS_DUMP=1

C6-heavy (min=257/max=768, ws=400, iters=1M)

  • v2 OFF (HOTHEAP_V2=0): 42.15M ops/s, HEAP_STATS[7] fast=283169 slow=1。
  • v2 ON (HOTHEAP_V2=1, classes=0x40): 29.69M ops/s。HEAP_STATS[6] fast=266914 slow=16。HOTHEAP_V2_STATS cls6 route_hits=0 / free_fb_v1=266930（実質 v1 経路）、fail=0。

Mixed 16–1024B (ws=400, iters=1M)

  • C7 v2 only (classes=0x80): 45.07M ops/s。HEAP_STATS[7] fast=283170 slow=2276、v2 alloc_lease/refill=2276。
  • C6+C7 v2 (classes=0xC0): 35.65M ops/s。HEAP_STATS[6] fast=137306 slow=1 / cls7 slow=2276。HOTHEAP_V2_STATS cls6 route_hits=0、cls7 refills=2276。
  • 所感: C6 v2 は初回 A/B で大幅マイナスかつ v2 ルートが当たっていない。C7 v2 もこのプロファイルでは refill が 2,276 件と多く throughput 低下。v2 は研究箱のまま、デフォルトは v2 OFF。

Phase43'': 計測専用で C6/C7 を TinyHeap に載せた場合（v2 OFF）

Mixed 16–1024B (ws=256, iters=20000, class mask=0xC0, C6+C7)

  • ENV: HAKMEM_BENCH_MIN_SIZE=16 HAKMEM_BENCH_MAX_SIZE=1024 HAKMEM_TINY_HEAP_PROFILE=C7_SAFE HAKMEM_TINY_HEAP_CLASSES=0xC0 HAKMEM_TINY_C7_HOT=1 HAKMEM_TINY_C6_HOT=1 HAKMEM_TINY_HOTHEAP_V2=0 HAKMEM_TINY_LARSON_FIX=1 HAKMEM_TINY_HEAP_STATS=1 HAKMEM_TINY_HEAP_STATS_DUMP=1 HAKMEM_TINY_FRONT_CLASS_STATS=1
  • Throughput: 32,227,500 ops/s（性能は大幅に低下、計測専用）
  • HEAP_STATS:
    • cls6: fast=2744 slow=1 free_fast_local=2745
    • cls7: fast=5691 slow=1 free_fast_local=4572
  • FRONT_CLASS alloc: cls2=147 cls3=341 cls4=720 cls5=1420 cls6=2745 cls7=5692

Tiny-only 8–128B (ws=256, iters=20000, class mask=0xC0, C6+C7)

  • ENV: HAKMEM_BENCH_MIN_SIZE=8 HAKMEM_BENCH_MAX_SIZE=128 HAKMEM_TINY_HEAP_PROFILE=C7_SAFE HAKMEM_TINY_HEAP_CLASSES=0xC0 HAKMEM_TINY_C7_HOT=1 HAKMEM_TINY_C6_HOT=1 HAKMEM_TINY_HOTHEAP_V2=0 HAKMEM_TINY_LARSON_FIX=1 HAKMEM_TINY_HEAP_STATS=1 HAKMEM_TINY_HEAP_STATS_DUMP=1 HAKMEM_TINY_FRONT_CLASS_STATS=1
  • Throughput: 63,341,251 ops/s
  • HEAP_STATS: 出力なし（対象クラスが 5 未満中心のため？）

所感

  • C6 を TinyHeap 経由にすると Mixed で大きくマイナス（32M）。cls6/7 の slow はいずれも 1 なので、性能低下はフロント/ホットパスの命令数増が主因と見られる。
  • 計測目的でのみクラスマスクを広げるのは有効だが、本番プロファイルは C7 のみ TinyHeap (0x80) を維持するのが安全。

Phase48: first-touch/page-fault 実験用プロファイルの固定

  • 評価は以下で統一し、pf/sys A/B の基準にする:
    • HAKMEM_BENCH_MIN_SIZE=16 HAKMEM_BENCH_MAX_SIZE=1024 HAKMEM_TINY_HEAP_PROFILE=C7_SAFE HAKMEM_TINY_HOTHEAP_V2=0 HAKMEM_TINY_LARSON_FIX=1
    • perf stat メトリクス: ops/s, page-faults, task-clock(user/sys), cycles, instructions
  • 目的: HugePage/first-touch 削減などの実験をこのプロファイルで比較し、pf がどれだけ減るかを確認する。

Phase45: 16–1024B perf stat A/B（HAKMEM vs mimalloc vs system, ws=400, iters=1,000,000, v2 OFF, C7 SAFE）

共通ENV: HAKMEM_BENCH_MIN_SIZE=16 HAKMEM_BENCH_MAX_SIZE=1024

Allocator Throughput (ops/s) cycles instructions IPC task-clock user/sys page-faults
HAKMEM (C7_SAFE, v2 OFF) 40,623,450 181,136,824 372,126,696 2.05 46.82 ms 29.4 ms / 18.5 ms 6,659
mimalloc 112,895,946 38,800,615 59,184,115 1.53 10.66 ms 10.31 ms / 1.41 ms 146
system malloc 92,111,481 52,144,974 107,607,240 2.06 12.54 ms 12.27 ms / 1.36 ms 133

所感/次手候補:

  • HAKMEM は sys 時間と page-fault が顕著（pf が mimallocの ~45x, sys 時間が高い）。pf/sys 寄りのボトルネックが支配的に見える。
  • 次の箱候補:
    • pf/sys 改善を狙う: Superslab/Warm Pool/pagefault 周りのCold Box見直し。
    • 命令数削減: front整理は済みなので、Tiny v1ホットパスや mid/large を軽くする路線も候補。

メモ

  • HEAP_STATS（fast/slow）のダンプが出ない状態。今後のベンチでは HAKMEM_TINY_HEAP_STATS[_DUMP] の有効化経路を再確認する必要あり。

Phase46: pf/sys 内訳の初期確認（HAKMEM, 16–1024B, ws=400, iters=1,000,000, v2 OFF, C7_SAFE）

  • perf record -o perf.data.pf -e page-faults -- ./bench_random_mixed_hakmem 1000000 400 1
  • perf report --stdio -i perf.data.pf
  • サマリ: page-fault サンプルの ~96% が __memset_avx2_unaligned_erms（初回タッチ系）。カーネル側の munmap/madvise 由来はほぼ見えず、残っている 6.6k faults は first-write が中心と推定。
  • 基準プロファイル（以降 pf/sys A/B の基準にする想定）:
    • HAKMEM_BENCH_MIN_SIZE=16 HAKMEM_BENCH_MAX_SIZE=1024 HAKMEM_TINY_HEAP_PROFILE=C7_SAFE HAKMEM_TINY_HOTHEAP_V2=0 HAKMEM_TINY_LARSON_FIX=1
  • TODO / 次の箱候補:
    • WarmPool / Superslab 再利用が十分効いているかの stats 確認（該当 ENV を後続で調査）。
    • empty Superslab を即 OS 返却していないかのポリシー確認。
    • pf/sys 系の変更は上記プロファイルで揃えて A/B を取る。

Phase46': WarmPool stats 1 回だけ確認（Mixed 16–1024B, ws=256, iters=20k, v2 OFF, C7_SAFE）

  • ENV: HAKMEM_BENCH_MIN_SIZE=16 HAKMEM_BENCH_MAX_SIZE=1024 HAKMEM_TINY_HEAP_PROFILE=C7_SAFE HAKMEM_TINY_HOTHEAP_V2=0 HAKMEM_TINY_LARSON_FIX=1 HAKMEM_WARM_POOL_STATS=1
  • 結果（stderr 抜粋）:
    • WarmPool-STATS: C7 hits=173 / misses=1 / prefilled=1（約 99.4% ヒット）。C2/C3/C4/C6 は warmup/prefill の 1 miss/1 prefill のみ。C0/C1/C5 は 0。
    • WARM logs: REL_C7_WARM_PREFILL calls=1 slabs=1, REL_C7_CARVE attempts=173 success=173, REL_C7_WARM pop=174 push=173.
    • Throughput: 43,809,979 ops/s（ws=256, iters=20k）。
  • 所感:
    • C7 は warm pool でほぼヒットしており、残り pf は first-write 優位という推定と矛盾しない。
    • 他クラスの warm pool はほぼ未使用（prefill 1 回のみ）。Mixed での pf/sys は C7 以外の Superslab 利用状況も別途見る必要あり。

Phase49: Mixed 16–1024B userland-only CPU パス観測（v2 OFF, C7_SAFE）

  • ENV: 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_TINY_LARSON_FIX=1
  • perf stat（1M iters, ws=400, userlandのみ）: throughput=41,000,086 ops/s, cycles=126,239,279, instructions=324,810,642（IPC≈2.57）, branch-misses=1,186,675, time=0.0438s（user 0.0295s / sys 0.0143s）
  • perf record（cycles:u, 1M/400）上位シンボル（self%基準、子なし集計）:
    • free 24.3%（libc wrapper経由の前段処理）
    • malloc 18.0%
    • main 15.3%（ベンチハーネス）
    • tiny_heap_page_pop 8.8%（TinyHeapBox hot pop）
    • hak_super_lookup 7.9%（frontからの Superslab 判定）
    • tiny_heap_page_becomes_empty 5.9%（empty 処理）
    • __memset_avx2_unaligned_erms 4.0%（ユーザランド側の初期化）
    • tiny_region_id_write_header 2.4%
  • 所感: ベンチ前段の malloc/free/main が重いが、TinyHeapBox 側では pop / super_lookup / empty が目立つ。Phase50 では TinyHeapBox（pop/empty + super_lookup 周辺）の枝削減を優先候補にする。

Phase47: Superslab OS ポリシーと OS 呼び出し可視化

  • Superslab取得パス: LRU pop → 旧 cache pop → ss_os_acquire(mmap、必要なら MAP_POPULATE / prefault touch) の順。mmap 成功時に g_ss_mmap_count + SS_OS_STATS alloc を更新。
  • Superslab解放パス: registry unregister → LRU push（成功時は MADV_DONTNEED で lazy zero、今回 madvise カウント追加）→ 旧 cache push → どちらも満杯なら即 munmap（SS_OS_STATS free を加算）。ss_cache が容量縮小で munmap した場合も free をカウント。
  • 新 ENV: HAKMEM_SS_OS_STATS=1 で alloc/free/madvise を destructor 1 行でダンプ（[SS_OS_STATS] alloc=… free=… madvise=…）。基準プロファイル（16–1024B, ws=400, iters=1M, C7_SAFE, v2 OFF）で 1 回回して OS 呼び出し回数を確認予定。
  • SS_OS_STATS（16–1024B, ws=400, iters=1M, C7_SAFE, v2 OFF）: alloc=2 / free=3 / madvise=2 / mmap_total=2 → OS 呼び出しは少数。残る 6.6k pf は first-write 優位と見るのが妥当。

Phase47: C6-heavy CPU ホットパスの初期観測（v2 OFF, C7_SAFE）

  • ベンチ (ws=256, iters=20k, C6-heavy):
    • ENV: HAKMEM_BENCH_MIN_SIZE=257 HAKMEM_BENCH_MAX_SIZE=768 HAKMEM_TINY_HEAP_PROFILE=C7_SAFE HAKMEM_TINY_C7_HOT=1 HAKMEM_TINY_HOTHEAP_V2=0 HAKMEM_TINY_LARSON_FIX=1 HAKMEM_TINY_FRONT_CLASS_STATS=1 HAKMEM_TINY_HEAP_STATS=1 HAKMEM_TINY_HEAP_STATS_DUMP=1
    • Throughput: 39,457,304 ops/s
    • FRONT_CLASS: cls6 alloc/free=5373、cls7 alloc=5692 free=4573
    • HEAP_STATS cls7: fast=5691 slow=1、C7_PAGE_STATS prepare_calls=1
  • perf stat (1M, ws=400, same ENV):
    • Throughput: 41,295,709 ops/s
    • cycles=175,790,796 / instructions=368,496,560 (IPC≈2.10) / task-clock=42.36 ms (user 27.26 ms / sys 16.13 ms) / branch-misses=2,206,657
  • perf record (cycles, 1M, ws=400):
    • ホットスポットは匿名ページフォルト経路に集中（__memset_avx2_unaligned_erms → handle_mm_fault → do_anonymous_page が包含 60%超）。
    • ユーザランド側では free/malloc が目立つがカーネルの first-touch が支配的。
  • 所感: C6-heavy でも pf/sys が依然大きく、C6/Tiny フロントより先に first-touch/zero の扱いを考える必要がある（prefault/warm 再利用の検討）。

Phase50: Tiny ヘッダモード (full/light/off) A/B（first-touch 実験の一部）

  • 目的: tiny_region_id_write_header のヘッダ書き込み/guard 初期化を軽量化することで page-fault / cycles がどこまで動くかを確認。
  • 実装概要:
    • ENV HAKMEM_TINY_HEADER_MODE=full|light|off を追加（未指定は full）。
      • full: 従来どおり region_id ヘッダと guard/初期化を常に書き戻す。
      • light: 既存ヘッダと一致する場合は再書き込みを避け、差分のみ最小限書く。
      • off: 既存ヘッダが壊れている場合のみ最小限のヘッダを書き戻し、guard 呼び出しや追加初期化はスキップ（free 整合性の最低限のみ保証）。旧 HAKMEM_TINY_WRITE_HEADER=0 は off 相当として互換維持。
    • FIRST_TOUCH_PAGEFAULT_REDUCTION_PLAN.md に 3 モードの設計と ENV を明記（bench 専用 opt-in モードとして扱う）。

Mixed 16–1024B (ws=400, iters=1M, PROFILE=C7_SAFE, v2 OFF, LARSON_FIX=1)

  • 共通 ENV: 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_TINY_LARSON_FIX=1
  • HEADER_MODE=full:
    • Throughput: 42,399,649 ops/s
    • cycles: 176,079,783
    • page-faults: 6,662
    • task-clock: 42.16 ms（user 25.1 ms / sys 17.8 ms）
  • HEADER_MODE=light:
    • Throughput: 38,752,779 ops/s
    • cycles: 187,089,553
    • page-faults: 6,661
    • task-clock: 44.16 ms（user 31.5 ms / sys 13.2 ms）
  • HEADER_MODE=off:
    • Throughput: 39,330,655 ops/s
    • cycles: 183,795,801
    • page-faults: 6,662
    • task-clock: 43.43 ms（user 29.3 ms / sys 15.2 ms）

所感（ヘッダモード実験）

  • page-fault 回数は full/light/off いずれも ≈6.66k とほぼ同一で、ヘッダ書き込み軽量化では first-touch page-fault は減らない。
  • cycles/ops はむしろ full が最も良く、light/off はそれぞれ約 -9% / -7% 程度の性能低下。判定・分岐コストがヘッダ書き込み削減効果を上回っている。
  • 結論として、現時点の実装では 運用デフォルトは full のままが最良。light/off は bench 専用の実験モードとして残し、本番プロファイルでは使用しない前提とする。

Phase52: Superslab HugePage 実験 (Mode A) – 初期結果

  • 目的: Superslab を HugePage (2MB) で確保する実験経路を追加し、page-fault / sys 時間がどこまで動くかを見る（研究専用）。
  • 実装概要:
    • ENV:
      • HAKMEM_SS_HUGEPAGE_EXPERIMENT=1 で HugePage 経路を opt-in（デフォルト 0）。
      • HAKMEM_SS_HUGEPAGE_SIZE でページサイズを指定（現状は "2M" 前提で実装）。
    • ss_os_acquire 周辺に HugePage 試行を追加し、MAP_HUGETLB | MAP_HUGE_2MB で mmap を試し、失敗時は即通常の 1MB Superslab 経路にフォールバック。
    • SS_OS_STATS に huge_alloc / huge_fail を追加し、HAKMEM_SS_OS_STATS=1 で [SS_OS_STATS] alloc=.. free=.. madvise=.. huge_alloc=.. huge_fail=.. を 1 行出力。

Mixed 16–1024B (ws=400, iters=1M, PROFILE=C7_SAFE, v2 OFF, LARSON_FIX=1)

  • 共通 ENV: 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_TINY_LARSON_FIX=1 HAKMEM_SS_OS_STATS=1
  • HugePage OFF:
    • Throughput: 41,464,379 ops/s
    • cycles: 180,862,510
    • page-faults: 6,660
    • SS_OS_STATS: alloc=2 free=4 madvise=2 mmap_total=2 fallback_mmap=0 huge_alloc=0 huge_fail=0
  • HugePage ON (HAKMEM_SS_HUGEPAGE_EXPERIMENT=1, HAKMEM_SS_HUGEPAGE_SIZE=2M):
    • Throughput: 41,372,856 ops/s
    • cycles: 177,305,948
    • page-faults: 6,662
    • SS_OS_STATS: alloc=2 free=4 madvise=2 mmap_total=2 fallback_mmap=0 huge_alloc=0 huge_fail=0

所感（HugePage 実験初期結果）

  • 現状の Superslab サイズ/条件では HugePage 経路が一度もヒットせず（huge_alloc=0 / huge_fail=0）、通常 Superslab 経路のみが使用されている。
  • そのため HugePage ON/OFF で throughput / cycles / page-fault はほぼ同一となり、初期実装の段階では効果は「ゼロに近い」。
  • 2MB Superslab 専用クラスを設計するか、サイズ条件を緩めて HugePage を実際に使うかを決めないと、Mode A の効果は評価できない。
  • 一方で pf はすでに ≈6.6k と小さく、たとえ HugePage でさらに削っても全体への寄与は限定的なため、現時点では CPU ホットパス側の最適化を優先し、HugePage 実験は research-only の位置付けに留める のが妥当と見える。

Phase59: C7 HotHeap v2 Mixed A/B（C7-only route ON/OFF）

  • プロファイル: HAKMEM_BENCH_MIN_SIZE=16 HAKMEM_BENCH_MAX_SIZE=1024 HAKMEM_TINY_HEAP_PROFILE=C7_SAFE HAKMEM_TINY_C7_HOT=1 HAKMEM_TINY_LARSON_FIX=1 HAKMEM_TINY_HEAP_STATS=1 HAKMEM_TINY_HEAP_STATS_DUMP=1 HAKMEM_TINY_HOTHEAP_CLASSES=0x80
  • v2 OFF (HAKMEM_TINY_HOTHEAP_V2=0):
    • Throughput: 45,113,732 ops/s
    • HEAP_STATS[7]: fast=5691 slow=1
    • C7_PAGE_STATS: prepare_calls=1（current を握り続けている）
  • v2 ON (HAKMEM_TINY_HOTHEAP_V2=1, HAKMEM_TINY_HOTHEAP_V2_STATS=1):
    • Throughput: 46,209,226 ops/s（約 +2.4%）
    • HEAP_STATS[7]: fast=5692 slow=45
    • HOTHEAP_V2_C7_STATS: route_hits=5692, alloc_fast=5692, alloc_lease=45 (=refill=45), cold_refill_fail=0, free_fast=4376, page_retired=4, fallback_v1=0
  • 所感:
    • Mixed でも v2 ON で微増（+2〜3%）だが、slow_prepare/alloc_lease が 45 と多く、current/partial を使い切る前に refill が走っている可能性がある。
    • cold_refill_fail/fallback は 0 のため、境界は安定。次は v2 内で空ページを握る／refill の発生頻度を下げる調整が必要。

Phase60: C7 HotHeap v2 空ページ保持ポリシー（partial 温存）初期ベンチ

  • 変更点: max_partial_pages を C7 用に 2 へ設定し、free で used==0 のページは retire せず partial へ温存。partial が上限を超えたときだけ retire。partial push/pop/peak/retire_v2 を v2 stats に追加。
  • C7-only (ws=64, iters=20k, PROFILE=C7_SAFE):
    • v2 OFF: 41.94M ops/s, HEAP_STATS[7] fast=11015 slow=1。
    • v2 ON: 50.43M ops/s, HEAP_STATS[7] fast=11016 slow=48。HOTHEAP_V2_C7_STATS: alloc_lease=48 (=refill), partial_push/pop/peak=0, retire_v2=0。
    • メモ: workload が常時多数の live ブロックを持つため page が空にならず、partial_push/retire はまだ発火していない。slow≈refill となっており、ページ容量/同時 live 数が原因と推定。
  • Mixed 16–1024B (ws=256, iters=20k, PROFILE=C7_SAFE):
    • v2 OFF: 42.82M ops/s, HEAP_STATS[7] fast=5691 slow=1。
    • v2 ON: 47.71M ops/s, HEAP_STATS[7] fast=5692 slow=42。HOTHEAP_V2_C7_STATS: alloc_lease=42 (=refill), partial_push/pop/peak=0, retire_v2=0。
  • 所感:
    • slow_prepare は「refill したページ数」と一致しており、空ページ保持ポリシーはまだ効く場面に遭遇していない（ページが一度も空にならないワークロード）。
    • v2 は C7-only/Mixed ともプラスを維持（+20% 近い向上）だが、refill=slow が 40〜50 回発生。partial を効かせるには「空になるページ」が出るプロファイルで検証するか、ページ容量/lease 戦略の見直しが必要。
  • 備考（容量と live 数）:
    • C7 の page capacity は 32 blocks（約 32KiB）で、ws=64/256/400 の Mixed では常時多数の live ブロックが存在するため、空 page がほぼ発生しない。partial/retire は保険として温存しつつ、現行ベンチでは出番がない前提で扱う。

Phase61: C7 v2 長尺 Mixed (ws=400, iters=1M) 安定性確認

  • プロファイル: Mixed 16–1024B, ws=400, iters=1M, PROFILE=C7_SAFE, C7_HOT=1, v2 classes=0x80, LARSON_FIX=1, STATS_BOX=on, STATS_BATCH=0。
  • v2 OFF: 41.58M ops/s。HEAP_STATS[7] fast=283169 slow=1。cold_refill_fail=0, fallback_v1=0。
  • v2 ON: 42.41M ops/s（約 +2%）。HEAP_STATS[7] fast=283169 slow=1。v2 stats dumpはなし（fail/fallbackなし）。
  • 所感:
    • 長尺でも v2 ON で安定稼働し、+2% 程度の改善を維持。slow_prepare は 1 に張り付き、短尺で見えていた refill 多発は長尺では再現せず。
    • 引き続き v2 は C7-only の研究箱（デフォルト OFF）のまま、Mixed でも回帰しないことを確認。

Phase61’(短尺再確認): Mixed 16–1024B (ws=256, iters=20k)

  • v2 OFF: 43.27M ops/s, HEAP_STATS[7] fast=5691 slow=1。
  • v2 ON (C7-only v2, classes=0x80, v2 stats ON): 44.57M ops/s（約 +3%）、HEAP_STATS[7] fast=5691 slow=1、cold_refill_fail/fallback=0。C7_PAGE_STATS: prepare_calls=1 で安定。
  • 所感: 20k/256 でも slow_prepare は 1 に収まり、v2 ON で軽いプラスを維持。長尺と同様に安定。partial/retire ポリシーは依然発火せず（ページが空にならない負荷のため）、本線 Mixed では v2 を研究箱として継続しつつ、さらなる薄型化/slow圧縮を検討。