fix(aspacem): raise amd64 managed address ceiling to 1 TiB#22
fix(aspacem): raise amd64 managed address ceiling to 1 TiB#22not-matthias wants to merge 1 commit into
Conversation
snmalloc-rs as a global allocator aborts under Callgrind because its startup mmap of a flat 256 GiB MAP_NORESERVE range returns EINVAL. On amd64-linux the address-space manager capped the managed range at 128 GiB, placing vStart (the client/Valgrind split) at ~64 GiB, so the largest floating client hole was ~62 GiB and any larger reservation was vetoed by VG_(am_get_advisory). Raise aspacem_maxAddr to 1 TiB (vStart ~512 GiB, ~512 GiB client hole), scoped to VGP_amd64_linux so other 64-bit ports keep 128 GiB (some arm64 kernels expose only a 39-bit user VA). No effect on Callgrind placement semantics; the fork ships only the 64-bit Callgrind tool. Refs COD-3073
7d8cb8b to
5714dad
Compare
Greptile SummaryRaises the managed address ceiling for
Confidence Score: 5/5Safe to merge; the change is a single, narrowly-scoped constant bump behind a platform guard with all existing invariants preserved. The modification is one additional preprocessor branch setting a constant. The value (1 TiB = 2^40) fits well inside the 47-bit amd64 user-space VA, the ENABLE_INNER safety cap that clamps the ceiling to sp_at_startup still applies after the new block, and the page-alignment assertion at startup continues to pass because 0x10000000000 is page-aligned. All other 64-bit Linux targets are unaffected by the else branch. No files require special attention; the single changed file is the right place for this constant. Important Files Changed
|
Merging this PR will not alter performance
Comparing Footnotes
|
Raises amd64
aspacem_maxAddrfrom 128 GiB to 1 TiB so a client can float a 256 GiBMAP_NORESERVEreservation (e.g. snmalloc) under Callgrind instead of gettingEINVAL. Scoped toVGP_amd64_linux.Refs COD-3073