|
|
22a67e5cab
|
Priority-2 ENV Cache: hakmem_smallmid.c (1変数追加、1箇所置換)
【追加ENV変数】
- HAKMEM_SMALLMID_ENABLE (default: 0)
【置換ファイル】
- core/hakmem_smallmid.c (1箇所 → ENV Cache)
【変更詳細】
1. ENV Cache (hakmem_env_cache.h):
- 構造体に1変数追加 (46→47変数)
- hakmem_env_cache_init()に初期化追加
- アクセサマクロ追加
- カウント更新: 46→47
2. hakmem_smallmid.c:
- smallmid_is_enabled():
getenv("HAKMEM_SMALLMID_ENABLE") → HAK_ENV_SMALLMID_ENABLE()
- #include "hakmem_env_cache.h" 追加
【効果】
- SmallMid有効化チェックからgetenv()呼び出しを排除
- Warm path起動時のENV参照を1回に削減
【テスト】
✅ make shared → 成功
✅ /tmp/test_mixed3_final → PASSED
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
|
2025-12-02 20:55:31 +09:00 |
|
|
|
8786d58fc8
|
Phase 17-2: Small-Mid Dedicated SuperSlab Backend (実験結果: 70% page fault, 性能改善なし)
Summary:
========
Phase 17-2 implements dedicated SuperSlab backend for Small-Mid allocator (256B-1KB).
Result: No performance improvement (-0.9%), worse than Phase 17-1 (+0.3%).
Root cause: 70% page fault (ChatGPT + perf profiling).
Conclusion: Small-Mid専用層戦略は失敗。Tiny SuperSlab最適化が必要。
Implementation:
===============
1. Dedicated Small-Mid SuperSlab pool (1MB, 16 slabs/SS)
- Separate from Tiny SuperSlab (no competition)
- Batch refill (8-16 blocks per TLS refill)
- Direct 0xb0 header writes (no Tiny delegation)
2. Backend architecture
- SmallMidSuperSlab: 1MB aligned region, fast ptr→SS lookup
- SmallMidSlabMeta: per-slab metadata (capacity/used/carved/freelist)
- SmallMidSSHead: per-class pool with LRU tracking
3. Batch refill implementation
- smallmid_refill_batch(): 8-16 blocks/call (vs 1 in Phase 17-1)
- Freelist priority → bump allocation fallback
- Auto SuperSlab expansion when exhausted
Files Added:
============
- core/hakmem_smallmid_superslab.h: SuperSlab metadata structures
- core/hakmem_smallmid_superslab.c: Backend implementation (~450 lines)
Files Modified:
===============
- core/hakmem_smallmid.c: Removed Tiny delegation, added batch refill
- Makefile: Added hakmem_smallmid_superslab.o to build
- CURRENT_TASK.md: Phase 17 完了記録 + Phase 18 計画
A/B Benchmark Results:
======================
| Size | Phase 17-1 (ON) | Phase 17-2 (ON) | Delta | vs Baseline |
|--------|-----------------|-----------------|----------|-------------|
| 256B | 6.06M ops/s | 5.84M ops/s | -3.6% | -4.1% |
| 512B | 5.91M ops/s | 5.86M ops/s | -0.8% | +1.2% |
| 1024B | 5.54M ops/s | 5.44M ops/s | -1.8% | +0.4% |
| Avg | 5.84M ops/s | 5.71M ops/s | -2.2% | -0.9% |
Performance Analysis (ChatGPT + perf):
======================================
✅ Frontend (TLS/batch refill): OK
- Only 30% CPU time
- Batch refill logic is efficient
- Direct 0xb0 header writes work correctly
❌ Backend (SuperSlab allocation): BOTTLENECK
- 70% CPU time in asm_exc_page_fault
- mmap(1MB) → kernel page allocation → very slow
- New SuperSlab allocation per benchmark run
- No warm SuperSlab reuse (used counter never decrements)
Root Cause:
===========
Small-Mid allocates new SuperSlabs frequently:
alloc → TLS miss → refill → new SuperSlab → mmap(1MB) → page fault (70%)
Tiny reuses warm SuperSlabs:
alloc → TLS miss → refill → existing warm SuperSlab → no page fault
Key Finding: "70% page fault" reveals SuperSlab layer needs optimization,
NOT frontend layer (TLS/batch refill design is correct).
Lessons Learned:
================
1. ❌ Small-Mid専用層戦略は失敗 (Phase 17-1: +0.3%, Phase 17-2: -0.9%)
2. ✅ Frontend実装は成功 (30% CPU, batch refill works)
3. 🔥 70% page fault = SuperSlab allocation bottleneck
4. ✅ Tiny (6.08M ops/s) is already well-optimized, hard to beat
5. ✅ Layer separation doesn't improve performance - backend optimization needed
Next Steps (Phase 18):
======================
ChatGPT recommendation: Optimize Tiny SuperSlab (NOT Small-Mid specific layer)
Box SS-Reuse (Priority 1):
- Implement meta->freelist reuse (currently bump-only)
- Detect slab empty → return to shared_pool
- Reuse same SuperSlab for longer (reduce page faults)
- Target: 70% page fault → 5-10%, 2-4x improvement
Box SS-Prewarm (Priority 2):
- Pre-allocate SuperSlabs per class (Phase 11: +6.4%)
- Concentrate page faults at benchmark start
- Benchmark-only optimization
Small-Mid Implementation Status:
=================================
- ENV=0 by default (zero overhead, branch predictor learns)
- Complete separation from Tiny (no interference)
- Valuable as experimental record ("why dedicated layer failed")
- Can be removed later if needed (not blocking Tiny optimization)
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
|
2025-11-16 03:21:13 +09:00 |
|
|
|
ccccabd944
|
Phase 17-1: Small-Mid Allocator - TLS Frontend Cache (結果: ±0.3%, 層分離成功)
Summary:
========
Phase 17-1 implements Small-Mid allocator as TLS frontend cache with Tiny backend delegation.
Result: Clean layer separation achieved with minimal overhead (±0.3%), but no performance gain.
Conclusion: Frontend-only approach is dead end. Phase 17-2 (dedicated backend) required for 2-3x target.
Implementation:
===============
1. Small-Mid TLS frontend (256B/512B/1KB - 3 classes)
- TLS freelist (32/24/16 capacity)
- Backend delegation to Tiny C5/C6/C7
- Header conversion (0xa0 → 0xb0)
2. Auto-adjust Tiny boundary
- When Small-Mid ON: Tiny auto-limits to C0-C5 (0-255B)
- When Small-Mid OFF: Tiny default C0-C7 (0-1023B)
- Prevents routing conflict
3. Routing order fix
- Small-Mid BEFORE Tiny (critical for proper execution)
- Fall-through on TLS miss
Files Modified:
===============
- core/hakmem_smallmid.h/c: TLS freelist + backend delegation
- core/hakmem_tiny.c: tiny_get_max_size() auto-adjust
- core/box/hak_alloc_api.inc.h: Routing order (Small-Mid → Tiny)
- CURRENT_TASK.md: Phase 17-1 results + Phase 17-2 plan
A/B Benchmark Results:
======================
| Size | Config A (OFF) | Config B (ON) | Delta | % Change |
|--------|----------------|---------------|----------|----------|
| 256B | 5.87M ops/s | 6.06M ops/s | +191K | +3.3% |
| 512B | 6.02M ops/s | 5.91M ops/s | -112K | -1.9% |
| 1024B | 5.58M ops/s | 5.54M ops/s | -35K | -0.6% |
| Overall| 5.82M ops/s | 5.84M ops/s | +20K | +0.3% |
Analysis:
=========
✅ SUCCESS: Clean layer separation (Small-Mid ↔ Tiny coexist)
✅ SUCCESS: Minimal overhead (±0.3% = measurement noise)
❌ FAIL: No performance gain (target was 2-4x)
Root Cause:
-----------
- Delegation overhead = TLS savings (net gain ≈ 0 instructions)
- Small-Mid TLS alloc: ~3-5 instructions
- Tiny backend delegation: ~3-5 instructions
- Header conversion: ~2 instructions
- No batching: 1:1 delegation to Tiny (no refill amortization)
Lessons Learned:
================
- Frontend-only approach ineffective (backend calls not reduced)
- Dedicated backend essential for meaningful improvement
- Clean separation achieved = solid foundation for Phase 17-2
Next Steps (Phase 17-2):
========================
- Dedicated Small-Mid SuperSlab backend (separate from Tiny)
- TLS batch refill (8-16 blocks per refill)
- Optimized 0xb0 header fast path (no delegation)
- Target: 12-15M ops/s (2.0-2.6x improvement)
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
|
2025-11-16 02:37:24 +09:00 |
|
|
|
cdaf117581
|
Phase 17-1 Revision: Small-Mid Front Box Only (ChatGPT Strategy)
STRATEGY CHANGE (ChatGPT reviewed):
- Phase 17-1: Build FRONT BOX ONLY (no dedicated SuperSlab backend)
- Backend: Reuse existing Tiny SuperSlab/SharedPool APIs
- Goal: Measure performance impact before building dedicated infrastructure
- A/B test: Does thin front layer improve 256-1KB performance?
RATIONALE (ChatGPT analysis):
1. Tiny/Middle/Large need different properties - same SuperSlab causes conflict
2. Metadata shapes collide - struct bloat → L1 miss increase
3. Learning signals get muddied - size-specific control becomes difficult
IMPLEMENTATION:
- Reduced size classes: 5 → 3 (256B/512B/1KB only)
- Removed dedicated SuperSlab backend stub
- Backend: Direct delegation to hak_tiny_alloc/free
- TLS freelist: Thin front cache (32/24/16 capacity)
- Fast path: TLS hit (pop/push with header 0xb0)
- Slow path: Backend alloc via Tiny (no TLS refill)
- Free path: TLS push if space, else delegate to Tiny
ARCHITECTURE:
Tiny: 0-255B (C0-C5, unchanged)
Small-Mid: 256-1KB (SM0-SM2, Front Box, backend=Tiny)
Mid: 8KB-32KB (existing)
FILES CHANGED:
- hakmem_smallmid.h: Reduced to 3 classes, updated docs
- hakmem_smallmid.c: Removed SuperSlab stub, added backend delegation
NEXT STEPS:
- Integrate into hak_alloc_api.inc.h routing
- A/B benchmark: Small-Mid ON/OFF comparison
- If successful (2x improvement), consider Phase 17-2 dedicated backend
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
|
2025-11-16 01:51:43 +09:00 |
|
|
|
993c5419b7
|
Phase 17-1: Small-Mid Allocator Box - Header and Stub Implementation
Created:
- core/hakmem_smallmid.h - API and size class definitions
- core/hakmem_smallmid.c - TLS freelist + ENV control (SuperSlab stub)
Design:
- 5 size classes: 256B/512B/1KB/2KB/4KB (SM0-SM4)
- TLS freelist structure (same as Tiny, completely separated)
- Header-based fast free (Phase 7 technology, magic 0xb0)
- ENV control: HAKMEM_SMALLMID_ENABLE=1 for A/B testing
- Dedicated SuperSlab pool (stub, Phase 17-2)
Boundaries:
Tiny: 0-255B (C0-C5, unchanged)
Small-Mid: 256B-4KB (SM0-SM4, NEW!)
Mid: 8KB-32KB (existing)
Implementation Status:
✅ TLS freelist operations (pop/push)
✅ ENV control (smallmid_is_enabled)
✅ Fast alloc (TLS hit path)
✅ Header-based free (0xb0 magic)
🚧 SuperSlab backend (stub, TODO Phase 17-2)
Goal: Bridge Tiny/Mid gap, improve 256B-1KB from 5.5M to 10-20M ops/s
Next: Phase 17-2 - Dedicated SuperSlab backend implementation
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
|
2025-11-16 01:43:29 +09:00 |
|