0546454168
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>
1.7 KiB
1.7 KiB
Learning Features A/B Benchmark Results
学習機能（ACE Controller / ELO / CAP/W_MAX Learner）の有無による性能差をまとめるためのファイルです。 ベンチ実行のたびに「条件 + 結果」をここに追記していき、論文や設計検証の基礎データとして利用します。
記録フォーマット（推奨）
- 共通メタデータ:
gitcommit:<hash>- Build: 例
make bench_random_mixed_hakmem,HAKMEM_TINY_HEADERLESS=1など - Bench: 実行コマンド（引数含む）
- 環境:
- CPU/メモリ/コア数（簡易でOK）
HAKMEM_MODE/HAKMEM_ACE_ENABLED/HAKMEM_LEARN/ その他主要 ENV
- 結果:
- Throughput (M ops/s)
- Page faults / RSS（わかる範囲で）
- 備考（学習の収束有無、安定までの時間など）
例:
[Run 2025-12-03]
- git: abcdef1
- Build: make bench_random_mixed_hakmem
- Bench: HAKMEM_MODE=balanced HAKMEM_ACE_ENABLED=0 HAKMEM_LEARN=0 ./bench_random_mixed_hakmem 256 100000 4
- Result: 72.3 M ops/s, PF=1.2e6, RSS=512MB
- Notes: Baseline (learning OFF)
[Run 2025-12-03]
- git: abcdef1
- Build: make bench_random_mixed_hakmem
- Bench: HAKMEM_MODE=balanced HAKMEM_ACE_ENABLED=1 HAKMEM_LEARN=0 ./bench_random_mixed_hakmem 256 100000 4
- Result: 78.1 M ops/s, PF=1.1e6, RSS=520MB
- Notes: ACE Controller ON, UCB1 収束後に +8% 前後の改善
現時点のメモ
- まだ本格的な学習 A/B データはここに集約されていません。
- すでに存在する分析レポート（
ACE_PHASE1_TEST_RESULTS.md,MID_LARGE_FINAL_AB_REPORT.mdなど）の結果を、順次ここにも要約していくと、論文執筆時に参照しやすくなります。