Files
hakmem/docs/analysis/LEARNING_LAYER_OVERVIEW.md
Moe Charm (CI) 0546454168 WIP: Add TLS SLL validation and SuperSlab registry fallback
ChatGPT's diagnostic changes to address TLS_SLL_HDR_RESET issue.
Current status: Partial mitigation, but root cause remains.

Changes Applied:
1. SuperSlab Registry Fallback (hakmem_super_registry.h)
   - Added legacy table probe when hash map lookup misses
   - Prevents NULL returns for valid SuperSlabs during initialization
   - Status:  Works but may hide underlying registration issues

2. TLS SLL Push Validation (tls_sll_box.h)
   - Reject push if SuperSlab lookup returns NULL
   - Reject push if class_idx mismatch detected
   - Added [TLS_SLL_PUSH_NO_SS] diagnostic message
   - Status:  Prevents list corruption (defensive)

3. SuperSlab Allocation Class Fix (superslab_allocate.c)
   - Pass actual class_idx to sp_internal_allocate_superslab
   - Prevents dummy class=8 causing OOB access
   - Status:  Root cause fix for allocation path

4. Debug Output Additions
   - First 256 push/pop operations traced
   - First 4 mismatches logged with details
   - SuperSlab registration state logged
   - Status:  Diagnostic tool (not a fix)

5. TLS Hint Box Removed
   - Deleted ss_tls_hint_box.{c,h} (Phase 1 optimization)
   - Simplified to focus on stability first
   - Status:  Can be re-added after root cause fixed

Current Problem (REMAINS UNSOLVED):
- [TLS_SLL_HDR_RESET] still occurs after ~60 seconds of sh8bench
- Pointer is 16 bytes offset from expected (class 1 → class 2 boundary)
- hak_super_lookup returns NULL for that pointer
- Suggests: Use-After-Free, Double-Free, or pointer arithmetic error

Root Cause Analysis:
- Pattern: Pointer offset by +16 (one class 1 stride)
- Timing: Cumulative problem (appears after 60s, not immediately)
- Location: Header corruption detected during TLS SLL pop

Remaining Issues:
⚠️ Registry fallback is defensive (may hide registration bugs)
⚠️ Push validation prevents symptoms but not root cause
⚠️ 16-byte pointer offset source unidentified

Next Steps for Investigation:
1. Full pointer arithmetic audit (Magazine ⇔ TLS SLL paths)
2. Enhanced logging at HDR_RESET point:
   - Expected vs actual pointer value
   - Pointer provenance (where it came from)
   - Allocation trace for that block
3. Verify Headerless flag is OFF throughout build
4. Check for double-offset application in conversions

Technical Assessment:
- 60% root cause fixes (allocation class, validation)
- 40% defensive mitigation (registry fallback, push rejection)

Performance Impact:
- Registry fallback: +10-30 cycles on cold path (negligible)
- Push validation: +5-10 cycles per push (acceptable)
- Overall: < 2% performance impact estimated

Related Issues:
- Phase 1 TLS Hint Box removed temporarily
- Phase 2 Headerless blocked until stability achieved

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

Co-Authored-By: Claude <noreply@anthropic.com>
2025-12-03 20:42:28 +09:00

6.9 KiB
Raw Blame History

Learning Layer Overview (ACE / ELO / CAP Learner)

このドキュメントは、hakmem 内の「学習する箱」を縦に貫いて整理した総覧です。 実装は複数のファイル・フェーズに分かれていますが、Box Theory の観点では次の 3 つの箱に分解できます。


1. Box A: ELO + Evolution (L2 / BigCache / THP)

範囲

  • サイズ帯: おおむね ≥ 2MBBigCache / THP / batch madvise が関わる領域)
  • 箱の責務:
    • 大きな割り当てに対する mmap 閾値(いつ BigCache / THP を使うか)の選択
    • 戦略候補(しきい値)間の比較と「勝ち残り」管理

実装ファイル

  • core/hakmem_elo.{c,h} — ELO Rating Strategy Selection複数のしきい値候補にレーティング
  • core/hakmem_evo.h — LEARN → FROZEN → CANARY ライフサイクル
  • core/hakmem_config.{c,h}HAKMEM_MODE と FeaturesHAKMEM_FEATURE_ELO, HAKMEM_FEATURE_EVOLUTION
  • core/box/mid_large_config_box.hMID_LARGE_ELO_ENABLED マクロPGO/通常モード)

モード

  • FROZENデフォルト
    • HAKMEM_MODE=balanced / fast では features.learning に ELO は含まれるが、evo_phase = EVO_PHASE_FROZEN
    • 戦略は事前に決めたしきい値を使い続け、ランタイムでのレーティング更新は行わない。
  • LEARN開発・研究用
    • HAKMEM_MODE=learning / researchHAKMEM_FEATURE_EVOLUTION が有効。
    • ELO レーティングと Evolution 状態機械が動作し、しきい値を動的に調整。

Box Theory 観点

  • Hot path実際の割り当ては「現在のしきい値」を見るだけ。
  • レーティング更新・進化は 完全にオフパス(バックグラウンド) の箱に閉じ込める。
  • 切り戻しは:
    • HAKMEM_MODE 変更、または HAKMEM_DISABLE_ELO=1 で ELO を丸ごと無効化。

2. Box B: ACE Controller (L1 Mid/Large, UCB1-based Knob Tuning)

範囲

  • サイズ帯: 1KB〜2MBL1 ACE レイヤ: Mid / Large Pool
  • 箱の責務:
    • Mid/Large Pool の TLS capacity / drain threshold / bundle width などの「ノブ」を UCB1 で自動調整。
    • 断片化ストレスや巨大ワーキングセットに対して、オフパスでキャッシュ構成を最適化。

実装ファイル

  • core/hakmem_ace_controller.{c,h} — ACE Controller 本体
  • core/hakmem_ace_metrics.{c,h} — メトリクス収集箱throughput, llc_miss, backlog 等)
  • core/hakmem_ace_ucb1.{c,h} — UCB1 Multi-Armed Bandit 実装
  • core/box/hak_core_init.inc.hhkm_ace_controller_init() / hkm_ace_controller_start() 呼び出し

起動条件ENV

  • HAKMEM_ACE_ENABLED=1 で有効化(デフォルト 0
  • 主な補助 ENV:
    • HAKMEM_ACE_FAST_INTERVAL_MS(デフォルト 500ms
    • HAKMEM_ACE_SLOW_INTERVAL_MS(デフォルト 30000ms
    • HAKMEM_ACE_LOG_LEVEL0=off,1=info,2=debug

挙動

  • 有効時:
    • バックグラウンドで fast-loop / slow-loop を回し、compute_reward() の結果を UCB1 に渡してノブを更新。
    • Tiny / Mid / Large のホットパスは「現在のノブ値」を読むだけで、学習ロジックには触れない。
  • 無効時:
    • hkm_ace_controller_init() が早期 return し、ACE に関連するオーバーヘッドはほぼゼロ。

Box Theory 観点

  • ACE は「ポリシー箱」であり、実際の割り当て/解放箱には侵入しない。
  • 境界:
    • ノブの読み出しは mid_large_config_box 等の 1 箇所 から行う。
    • メトリクスの書き込みは hakmem_ace_metrics に集約alloc/free 側は軽量カウンタ更新のみ)。

3. Box C: CAP/W_MAX Learner + Tiny ACE Observer

範囲

  • Mid/Large Pool:
    • クラス別 CAPページ数 / バンドル数)と W_MAX許容丸め率の自動調整。
  • Tiny:
    • hak_tiny_superslab_ace_observe_all() による Tiny Superslab 利用状況の観測Phase 8.4)。

実装ファイル

  • core/hakmem_learner.{c,h} — CAP/W_MAX/THP 学習スレッド
  • core/hakmem_tiny_superslab.h — Tiny Superslab 監視用 APIACE Observer
  • core/box/hak_core_init.inc.hhkm_learner_init() 呼び出し

起動条件ENV

  • 学習スレッド:
    • HAKMEM_LEARN=1 で有効化(デフォルト 0
  • Tiny ACE Observer:
    • HAKMEM_ACE_OBSERVE=1 で Tiny Superslab の観測を ON。
    • 追加で HAKMEM_ACE_DEBUG=1 を付けると、観測呼び出しをログ出力。

挙動

  • 学習スレッドは:
    • 一定間隔(HAKMEM_LEARN_WINDOW_MS)でヒット率をサンプリング。
    • 目標ヒット率 (HAKMEM_TARGET_HIT_MID/LARGE) とのズレに応じて CAP を増減。
    • オプションで W_MAX 候補を UCB1 で試す(HAKMEM_WMAX_LEARN=1)。
  • Tiny ACE Observer は:
    • Superslab / Tiny キャッシュの利用状況をスキャンし、後続の設計/学習に使う「観測専用箱」。
    • 現時点では Tiny の動作そのものは変えず、将来の ACE-Alloc 設計のための下準備。

Box Theory 観点

  • CAP/W_MAX の調整は、hakmem_learner 箱の中だけで完結。
  • Mid/Large のホットパスは「現在の CAP / W_MAX」を見るだけで、学習状態を知らない。
  • Tiny は「Observer に観測される側」であり、ACE が Tiny のホットパスを直接いじらない設計になっている。

4. モードと組み合わせ(どこまで学習させるか)

グローバルモード (HAKMEM_MODE)

  • minimal:
    • ELO/ACE/CAP Learner などの学習箱はすべて OFF。
  • fast / balanced(デフォルト):
    • ELO: FROZEN学習オフ、しきい値のみ利用
    • ACE Controller: HAKMEM_ACE_ENABLED が 1 のときのみ動作
    • CAP Learner: HAKMEM_LEARN が 1 のときのみ動作
  • learning / research:
    • ELO: LEARN + EVOLUTION 有効
    • その他の箱も ENV に応じて積極的に動く前提。

推奨パターン(論文用 / 評価用)

  • Baseline:
    • HAKMEM_MODE=balancedHAKMEM_ACE_ENABLED=0HAKMEM_LEARN=0
  • ACE only:
    • HAKMEM_MODE=balancedHAKMEM_ACE_ENABLED=1HAKMEM_LEARN=0
  • CAP/W_MAX only:
    • HAKMEM_MODE=balancedHAKMEM_ACE_ENABLED=0HAKMEM_LEARN=1
  • Full learning:
    • HAKMEM_MODE=learningHAKMEM_ACE_ENABLED=1HAKMEM_LEARN=1

各パターンのベンチ結果は、docs/benchmarks/LEARNING_AB_RESULTS.md に逐次追記していく想定です。


5. 関連ドキュメント

  • 概要・設計:
    • docs/ACE_LEARNING_LAYER.md
    • docs/ACE_LEARNING_LAYER_PLAN.md
    • docs/design/ARCHITECTURE_DESIGN.md
  • 詳細分析:
    • docs/analysis/ACE_INVESTIGATION_REPORT.md
    • docs/analysis/ACE_POOL_ARCHITECTURE_INVESTIGATION.md
    • docs/analysis/ENV_CLEANUP_ANALYSIS.md
  • 論文ドラフト:
    • docs/paper/ACE-Alloc/main.md
    • メモ用: docs/paper/ACE_ALLOC_NOTES.md(今後作成・拡充予定)