tomoaki/hakmem
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
118c0e48570e291e326bbce372c39aeb4b047e79
hakmem/docs/status/CURRENT_TASK.md
Moe Charm (CI) 118c0e4857 Phase FREE-DISPATCHER-OPT-1: free dispatcher 統計計測 
**目的**: free dispatcher（29%）の内訳を細分化して計測。

**実装内容**:
- FreeDispatchStats 構造体追加（ENV: HAKMEM_FREE_DISPATCH_STATS, default 0）
- カウンタ: total_calls / domain (tiny/mid/large) / route (ultra/legacy/pool/v6) / env_checks / route_for_class_calls
- hak_free_at / tiny_route_for_class / tiny_route_snapshot_init にカウンタ埋め込み
- 挙動変更なし（計測のみ、ENV OFF 時は overhead ゼロ）

**計測結果**:

Mixed 16-1024B (1M iter, ws=400):
- total=8,081, route_calls=267,967, env_checks=9
- BENCH_FAST_FRONT により大半は早期リターン
- route_for_class は主に alloc 側で呼ばれる（267k calls vs 8k frees）
- ENV check は初期化時の 9回のみ（snapshot 効果）

C6-heavy (257-768B, 1M iter, ws=400):
- total=500,099, route_calls=1,034, env_checks=9
- fg_classify_domain に到達する free が多い
- route_for_class 呼び出しは極小（snapshot 効果）

**結論**:
- ENV check は既に十分最適化されている（初期化時のみ）
- route_for_class は alloc 側での呼び出しが主で、free 側は snapshot で O(1)
- 次フェーズ（OPT-2）では別のアプローチを検討

**ドキュメント追加**:
- docs/analysis/FREE_DISPATCHER_ANALYSIS.md（新規）
- CURRENT_TASK.md に Phase FREE-DISPATCHER-OPT-1 セクション追加

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
2025-12-11 21:21:40 +09:00

13 KiB
Raw Blame History

CURRENT TASK - Critical Bugs Fixed

Last Updated: 2025-11-29 Branch: master @ 6d40dc741 Scope: Header Corruption + Segfault 根治完了 - 完全安定化達成

🎉 2025-11-29 UPDATE: CRITICAL BUGS RESOLVED

✅ 完了した修正

1. Header Corruption Bug (Class 1) - 根治完了

  • 症状: [TLS_SLL_HDR_RESET] cls=1 got=0x00 expect=0xa1
  • 原因: freelist → TLS SLL の2パスで header 未復元
  • 修正: 両パスに header restoration 追加
  • 結果: 20-thread Larson で header corruption 完全消滅 ✅

Commits:

  • 3c6c76cb1 - box_carve_and_push_with_freelist() fix
  • a94344c1a - tiny_drain_freelist_to_sll_once() fix

2. Segmentation Fault Bug - 根治完了

  • 症状: larson_hakmem が intermittent に SEGV (~50% 確率)
  • 原因: superslab_allocate() の implicit int declaration → pointer corruption via sign extension
  • 修正: 2ファイルに #include "box/ss_allocation_box.h" 追加
  • 結果: larson_hakmem が完全安定動作 ✅

Commit:

  • 6d40dc741 - Add missing superslab_allocate() declaration

🔬 Task Agent の貢献

  • Header corruption: 全 freelist paths を網羅的調査、dead code path まで発見
  • Segfault: gdb + coredump で Assembly レベル解析、sign extension メカニズムを特定

📊 現在の安定性

Test Status
Larson 1T ✅ 安定動作 (51.95M ops/s)
Larson 4T ✅ 安定動作 (header validation 有効)
Larson 20T ✅ Header corruption 0 errors
Random Mixed ✅ 安定動作 (66.82M ops/s)
SuperSlab expansion ✅ Segfault 消滅

📋 Stable Master Established (2025-11-26)

Branch: master (formerly larson-master-rebuild) Scope: 安定版 master 確立完了 - Larson 動作 + 67M ops/s

🎯 現状サマリ

✅ 新 master 性能（安定版）

Benchmark Performance Status
Larson 1T 51.95M ops/s ✅ 安定動作 (0% crash)
Random Mixed 256B 66.82M ops/s ✅ 安定動作

Branch: master @ d26dd092b Architecture: E1-CORRECT (C0,C7 offset=0; C1-C6 offset=1)

📚 旧 master 保存（参考用）

  • Branch: master-80M-unstable @ 328a6b722
  • Random Mixed: ~80M ops/s
  • Larson: 100% クラッシュ (Step 2.5 バグ)
  • Architecture: UNIFIED-HEADER (全クラス offset=1)
  • 80M 達成経路: PERFORMANCE_HISTORY_62M_TO_80M.md 参照

📋 作業計画

Phase 0: 安定ベースライン確立 ✅ DONE

  • larson-fix ブランチから larson-master-rebuild 作成
  • Larson 動作確認 (51M ops/s)
  • Random Mixed 動作確認 (62M ops/s)

Phase 1: クリーンアップ & 安定化 ✅ DONE

目標: 安定状態でコードベースを整理

1.1 Cherry-pick 済み（7コミット）

  • 9793f17d6 レガシーコード削除 (-1,159 LOC)
  • cc0104c4e テストファイル削除 (-1,750 LOC)
  • 416930eb6 バックアップファイル削除 (-1,072 KB)
  • 225b6fcc7 死コード削除: UltraHot, RingCache等 (-1,844 LOC)
  • 2c99afa49 学習システムバグドキュメント
  • 328a6b722 Larsonバグ分析更新
  • 0143e0fed CONFIGURATION.md 追加

1.2 追加最適化

  • a2e65716b tiny_get_max_size inline化 (+2M ops/s期待値)
  • d35504163 Superslab Min-Keep ポート（後にリバート）
  • bea839add Min-Keep リバート（Larson 安定化）
  • d26dd092b Performance History ドキュメント作成

1.3 master 確立

  • 旧 master を master-80M-unstable にバックアップ
  • master ブランチを安定版 (d26dd092b) に更新
  • Larson 0% crash 確認 (51.95M ops/s)
  • Random Mixed 67M ops/s 確認

Phase 2: 性能最適化ポート 📊 PENDING

目標: 62M → 80M+ ops/s 回復

2.1 簡単なチューニング（独立・低リスク）

  • e81fe783d tiny_get_max_size inline化 (+2M)
  • 04a60c316 Superslab/SharedPool チューニング (+1M)
  • 392d29018 Unified Cache容量チューニング (+1M)
  • dcd89ee88 Stage 1 lock-free (+0.3M)

2.2 本丸（UNIFIED-HEADER）

  • 472b6a60b Phase UNIFIED-HEADER (+17%, C7ヘッダ統一)
  • d26519f67 UNIFIED-HEADERバグ修正 (+15-41%)
  • 165c33bc2 Larsonフォールバック修正（必要なら）

2.3 スキップ対象

  • ❌ 03d321f6b Phase 27 Ultra-Inline → -10~15%回帰
  • ❌ Step 2.5関連コミット → Larsonクラッシュの原因

Phase 3: 検証 & マージ 🔀 PENDING

  • Larson 10回平均ベンチマーク
  • Random Mixed 10回平均ベンチマーク
  • master ブランチ更新

🔍 根本原因分析

Larson クラッシュの原因

First Bad Commit: 19c1abfe7 "Fix Unified Cache TLS SLL bypass"

Step 2.5 が TLS_SLL_PUSH_DUP を「修正」するために追加されたが：

  1. TLS_SLL_PUSH_DUP は実際には発生しない（ベースで10M回テスト済み）
  2. Step 2.5 がマルチスレッド環境で cross-thread ownership 問題を引き起こす
  3. 結論：不要な「修正」が Larson を壊した

80M 達成の主要因

コミット 内容 改善幅
472b6a60b UNIFIED-HEADER (C7統一) +17%
d26519f67 UH バグ修正 +15-41%
その他チューニング inline, policy等 +4-5M

📁 関連ファイル

修正対象

  • core/front/tiny_unified_cache.c - Step 2.5 なしのまま維持
  • core/tiny_free_fast_v2.inc.h - LARSON_FIX 関連
  • core/box/ptr_conversion_box.h - UNIFIED-HEADER で変更予定

ドキュメント

  • LEARNING_SYSTEM_BUGS_P0.md - 学習システムバグ記録
  • CONFIGURATION.md - ENV変数リファレンス
  • PROFILES.md - 性能プロファイル

✅ 完了マイルストーン

  1. Larson 安定化 - 51M ops/s で動作 ✅
  2. Cherry-pick Phase 1 - 7コミット完了 ✅
  3. ベースライン確立 - 62M/51M で安定 ✅

Phase FREE-LEGACY-OPT シリーズ（2025-12-11）

Phase FREE-LEGACY-OPT-4-1: Legacy per-class 分析 ✅ 完了

目的: Legacy fallback 49.2% の内訳を per-class で分析

測定結果（Mixed 16-1024B）:

  • C6 (513-1024B): 51.4% (137,319 / 266,942 Legacy calls)
  • C5 (257-512B): 25.8%
  • C4 (129-256B): 13.0%
  • C3 (65-128B): 6.5%
  • C2 (33-64B): 3.3%
  • C0/C1/C7: 0.0%

最大ターゲット: C6 が Legacy の過半数を占める

詳細: docs/analysis/FREE_LEGACY_PATH_ANALYSIS.md 参照

Phase FREE-LEGACY-OPT-4-2: C6_ULTRA_FREE_BOX 実装（進行中）

目的: C6 の free だけを C7 ULTRA 風 TLS キャッシュで受け、Legacy fallback を半減

実装範囲:

  • C6 専用・free 専用（alloc は既存ルートのまま）
  • TLS に c6_freelist[32] + c6_count + segment range check
  • ENV: HAKMEM_TINY_C6_ULTRA_FREE_ENABLED=0（研究箱、デフォルト OFF）

期待効果:

  • Legacy fallback: 49.2% → 24-27%（C6 分を削減）
  • Mixed throughput: +5-8% 改善（44.8M → 47-48M ops/s）

🎯 次のアクション

現時点での選択肢

  1. Option A: 現状維持（推奨）

    • master @ 67M ops/s (Larson 安定)
    • 80M の知見は PERFORMANCE_HISTORY_62M_TO_80M.md と master-80M-unstable に保存済み
    • Phase 2 (性能最適化) は将来の作業として保留

  2. Option B: UNIFIED-HEADER ポート（高難度）

    • 80M 達成の主要因（+17% + +15-41%）
    • E1-CORRECT との互換性問題あり
    • 大規模な書き換えが必要
    • 詳細: PERFORMANCE_HISTORY_62M_TO_80M.md Section "Option 3"

  3. Option C: Step 2.5 Revert（失敗済み）

    • master-80M-unstable から Step 2.5 をリバート
    • 複雑な conflict (33行変更) で35+ 回失敗済み
    • 推奨しない

Phase PERF-ULTRA-REBASE-2: C4-C7 ULTRA free最適化後のperf再計測 (2025-12-11)

計測対象: Mixed 16-1024B, C6-heavy

計測条件

  • Mixed 16-1024B:

    • ENV: HAKMEM_PROFILE=MIXED_TINYV3_C7_SAFE
    • ULTRA: C4-C7 全て ON
    • ワークロード: iters=1M, ws=400
    • perf: -F 5000 --call-graph dwarf -e cycles:u

  • C6-heavy:

    • ENV: HAKMEM_PROFILE=C6_HEAVY_LEGACY_POOLV1
    • pool v1 + C6/C5/C4 ULTRA
    • ワークロード: 1 thread, iters=1M, ws=400

スループット

  • Mixed: 42.63M ops/s（前回 31.61M から大幅改善、但し ws=400 vs 8192の差）
  • C6-heavy: 26.49M ops/s

新しい最大ホットスポット（Mixed）

WARNING: サンプル数が極めて少ない（238 samples）

順位 関数 self% 分類
#1 free 27.88% ベンチマーク wrapper
#2 tiny_alloc_gate_fast 23.57% alloc gate/front
#3 main 17.66% ベンチマーク harness
#4 malloc 6.94% ベンチマーク wrapper
#5 header 書き込み合計 8.07% tiny_region_id_write_header

ULTRA 関連関数が全て不可視: tiny_c7_ultra_alloc や ULTRA free 群が上位20に入っていない

前フェーズ（PERF-ULTRA-FREE-OPT-1）との比較

  • 前回（ws=8192, iters=10M）: C7 ULTRA alloc 7.66%, ULTRA free群 5.41%, so_alloc 3.60%
  • 今回（ws=400, iters=1M）: これらが全て不可視（< 0.63%）
  • サンプル数: 前回1842 samples vs 今回238 samples（約1/8）

結論

  • 計測条件の再検討が必要: ワークロードが軽すぎ（iters=1M, ws=400）

    • perf サンプル数が238と極めて少なく、統計的信頼性が低い
    • ベンチマーク時間が0.023s（23ms）と極めて短く、allocator 本体が可視化されていない

  • 次の最大ボトルネックを確定できず:

    • gate/front（23.57%）と header（8.07%）が可視範囲での上位
    • ULTRA alloc/free の実態が見えていない

  • 推奨される次の手順:

    • iters を 10M に増やす、または ws を 8192 に拡大して再計測
    • サンプル数を1000+に増やして統計的信頼性を確保

C6-heavy 分析

  • pool v1 が支配的: alloc 14.46% + free 19.89% = 34.35%
  • ULTRA は可視化されず: C6/C5/C4 ULTRA 関数が上位に入っていない
  • pthread_once が8.21%: 初期化同期のオーバーヘッドが目立つ（ワークロードが軽い証拠）

出力物

  1. perf_ultra_mixed_v2.txt - Mixed の perf report 完全出力（238 samples）
  2. perf_ultra_c6_v2.txt - C6-heavy の perf report 完全出力（292 samples）
  3. 更新済み TINY_CPU_HOTPATH_USERLAND_ANALYSIS.md - 解析結果とWARNINGを記載
  4. 更新済み CURRENT_TASK.md - 本セクション

Phase PERF-ULTRA-REBASE-2 後の次フェーズ候補（要判断）

判断保留理由

  • サンプル不足: 現状の perf 結果では allocator 本体のボトルネックが可視化されていない
  • 再計測が必須: より重いワークロード（iters=10M, ws=8192）で再測定してから判断すべき

パターン分析（参考：前回 PERF-ULTRA-REBASE-1 の結果に基づく）

パターン A: tiny_c7_ultra_alloc が依然トップの場合

  • 前回の値: 7.66% self（最大ホットスポット）
  • 理由: ULTRA alloc の内部構造（refill/page_meta）に起因
  • 次フェーズ案: Phase PERF-ULTRA-REFILL-OPT-1
    • C7 ULTRA の refill path（cold 側）を最適化
    • segment 取得ロジックの軽量化
    • page_meta 管理の簡略化
  • 判断: C7 refill を弄る技術的難度と効果のバランスを検討

パターン B: so_alloc_fast / page_of が浮いてきた場合

  • 前回の値: so_alloc系 3.60%, page_of系 2.74%
  • 理由: ULTRA が C4-C7 を完全カバーし、v3 backend 側が relative に大きくなった
  • 次フェーズ案: Phase PERF-ULTRA-V3-OPT-1
    • so_alloc_v3 の hotpath 簡略化
    • page_of（ptr→page 解決）の高速化
    • header write の最適化（既に thin は確認済み）
  • 判断: v3 backend 自体を軽くするか、別 backend（v4/v6）を考えるか

パターン C: 残り legacy (C2/C3) が顕著な場合

  • 確認: legacy 総数が何%か、C2/C3 の比率を確認
  • 判断基準:
    • C2/C3 合計が全体の 5% 以上 → C3 ULTRA を検討する価値あり
    • C2/C3 合計が 2% 未満 → 後回し（L1 汚染のリスクが高い）

パターン D: tiny_alloc_gate_fast / header が上位の場合（今回観測）

  • 今回の値: gate 23.57%, header 8.07%
  • 理由: ワークロードが軽すぎて allocator 本体が見えていない可能性が高い
  • 次フェーズ案: Phase PERF-ULTRA-REBASE-3（再計測）
    • より重いワークロード（iters=10M, ws=8192）で再測定
    • サンプル数1000+を確保して統計的信頼性を高める
    • その上でパターンA/B/Cのどれかに該当するか判断

推奨される判断フロー

  1. Phase PERF-ULTRA-REBASE-3（再計測）を実施

    • iters=10M, ws=8192 で Mixed を再計測
    • perf record 時間を長くしてサンプル数を確保

  2. 再計測後の perf_ultra_mixed_v3.txt の #1/#2 を見る

    • パターン A/B/C/D のどれに該当するか判定

  3. 該当フェーズ案を実装 or 研究箱化の判断

    • A: ULTRA refill 最適化（高難度、効果大）
    • B: v3 backend 最適化（中難度、効果中）
    • C: C2/C3 ULTRA 追加（低難度、効果不明）
    • D: 再計測（必須）