hakmem/pool_tls.d

pool_tls.o: core/pool_tls.c core/pool_tls.h core/pool_tls_registry.h \
 core/pool_tls_bind.h
core/pool_tls.h:
core/pool_tls_registry.h:
core/pool_tls_bind.h:
P0 Lock Contention Analysis: Instrumentation + comprehensive report P0-2: Lock Instrumentation (✅ Complete) - Add atomic counters to g_shared_pool.alloc_lock - Track acquire_slab() vs release_slab() separately - Environment: HAKMEM_SHARED_POOL_LOCK_STATS=1 - Report stats at shutdown via destructor P0-3: Analysis Results (✅ Complete) - 100% contention from acquire_slab() (allocation path) - 0% from release_slab() (effectively lock-free!) - Lock rate: 0.206% (TLS hit rate: 99.8%) - Scaling: 4T→8T = 1.44x (sublinear, lock bottleneck) Key Findings: - 4T: 330 lock acquisitions / 160K ops - 8T: 658 lock acquisitions / 320K ops - futex: 68% of syscall time (from previous strace) - Bottleneck: acquire_slab 3-stage logic under mutex Report: MID_LARGE_LOCK_CONTENTION_ANALYSIS.md (2.3KB) - Detailed breakdown by code path - Root cause analysis (TLS miss → shared pool lock) - Lock-free implementation roadmap (P0-4/P0-5) - Expected impact: +50-73% throughput Files Modified: - core/hakmem_shared_pool.c: +60 lines instrumentation - Atomic counters: g_lock_acquire/release_slab_count - lock_stats_init() + lock_stats_report() - Per-path tracking in acquire/release functions Next Steps: - P0-4: Lock-free per-class free lists (Stage 1: LIFO stack CAS) - P0-5: Lock-free slot claiming (Stage 2: atomic bitmap) - P0-6: A/B comparison (target: +50-73%) 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com> 2025-11-14 15:32:07 +09:00			`pool_tls.o: core/pool_tls.c core/pool_tls.h core/pool_tls_registry.h \`
			`core/pool_tls_bind.h`
Tiny: fix header/stride mismatch and harden refill paths - Root cause: header-based class indexing (HEADER_CLASSIDX=1) wrote a 1-byte header during allocation, but linear carve/refill and initial slab capacity still used bare class block sizes. This mismatch could overrun slab usable space and corrupt freelists, causing reproducible SEGV at ~100k iters. Changes - Superslab: compute capacity with effective stride (block_size + header for classes 0..6; class7 remains headerless) in superslab_init_slab(). Add a debug-only bound check in superslab_alloc_from_slab() to fail fast if carve would exceed usable bytes. - Refill (non-P0 and P0): use header-aware stride for all linear carving and TLS window bump operations. Ensure alignment/validation in tiny_refill_opt.h also uses stride, not raw class size. - Drain: keep existing defense-in-depth for remote sentinel and sanitize nodes before splicing into freelist (already present). Notes - This unifies the memory layout across alloc/linear-carve/refill with a single stride definition and keeps class7 (1024B) headerless as designed. - Debug builds add fail-fast checks; release builds remain lean. Next - Re-run Tiny benches (256/1024B) in debug to confirm stability, then in release. If any remaining crash persists, bisect with HAKMEM_TINY_P0_BATCH_REFILL=0 to isolate P0 batch carve, and continue reducing branch-miss as planned. 2025-11-09 18:55:50 +09:00			`core/pool_tls.h:`
			`core/pool_tls_registry.h:`
P0 Lock Contention Analysis: Instrumentation + comprehensive report P0-2: Lock Instrumentation (✅ Complete) - Add atomic counters to g_shared_pool.alloc_lock - Track acquire_slab() vs release_slab() separately - Environment: HAKMEM_SHARED_POOL_LOCK_STATS=1 - Report stats at shutdown via destructor P0-3: Analysis Results (✅ Complete) - 100% contention from acquire_slab() (allocation path) - 0% from release_slab() (effectively lock-free!) - Lock rate: 0.206% (TLS hit rate: 99.8%) - Scaling: 4T→8T = 1.44x (sublinear, lock bottleneck) Key Findings: - 4T: 330 lock acquisitions / 160K ops - 8T: 658 lock acquisitions / 320K ops - futex: 68% of syscall time (from previous strace) - Bottleneck: acquire_slab 3-stage logic under mutex Report: MID_LARGE_LOCK_CONTENTION_ANALYSIS.md (2.3KB) - Detailed breakdown by code path - Root cause analysis (TLS miss → shared pool lock) - Lock-free implementation roadmap (P0-4/P0-5) - Expected impact: +50-73% throughput Files Modified: - core/hakmem_shared_pool.c: +60 lines instrumentation - Atomic counters: g_lock_acquire/release_slab_count - lock_stats_init() + lock_stats_report() - Per-path tracking in acquire/release functions Next Steps: - P0-4: Lock-free per-class free lists (Stage 1: LIFO stack CAS) - P0-5: Lock-free slot claiming (Stage 2: atomic bitmap) - P0-6: A/B comparison (target: +50-73%) 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com> 2025-11-14 15:32:07 +09:00			`core/pool_tls_bind.h:`