Skip to content

fix(aspacem): raise amd64 managed address ceiling to 1 TiB#22

Open
not-matthias wants to merge 1 commit into
masterfrom
cod-3073-investigate-valgrind-support-for-snmallocs-256-gib
Open

fix(aspacem): raise amd64 managed address ceiling to 1 TiB#22
not-matthias wants to merge 1 commit into
masterfrom
cod-3073-investigate-valgrind-support-for-snmallocs-256-gib

Conversation

@not-matthias

Copy link
Copy Markdown
Member

Raises amd64 aspacem_maxAddr from 128 GiB to 1 TiB so a client can float a 256 GiB MAP_NORESERVE reservation (e.g. snmalloc) under Callgrind instead of getting EINVAL. Scoped to VGP_amd64_linux.

Refs COD-3073

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
@not-matthias not-matthias force-pushed the cod-3073-investigate-valgrind-support-for-snmallocs-256-gib branch from 7d8cb8b to 5714dad Compare July 6, 2026 12:39
@greptile-apps

greptile-apps Bot commented Jul 6, 2026

Copy link
Copy Markdown

Greptile Summary

Raises the managed address ceiling for VGP_amd64_linux from 128 GiB to 1 TiB in aspacemgr-linux.c, enabling clients that rely on large lazy (MAP_NORESERVE) reservations (e.g. snmalloc under Callgrind) to obtain a contiguous hole of ~512 GiB instead of only ~64 GiB.

  • The change is correctly gated to #if defined(VGP_amd64_linux) inside the existing #if VG_WORDSIZE == 8 block; all other 64-bit Linux targets keep the 128 GiB value.
  • The constant 0x10000000000ULL is 2^40 = 1 TiB, confirmed within amd64's 47-bit user-space VA; the ENABLE_INNER safety cap that trims aspacem_maxAddr to sp_at_startup still applies unchanged after the new block.
  • Page-alignment assertions at startup (VG_IS_PAGE_ALIGNED(aspacem_maxAddr + 1)) continue to hold since 1 TiB is page-aligned.

Confidence Score: 5/5

Safe 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

Filename Overview
coregrind/m_aspacemgr/aspacemgr-linux.c Adds a VGP_amd64_linux-specific branch that sets aspacem_maxAddr to 1 TiB (0xFFFFFFFFFF) instead of 128 GiB; ENABLE_INNER cap and page-alignment invariants remain intact; hex constant and comments are correct.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[VG_am_startup called] --> B{VG_WORDSIZE == 8?}
    B -- No --> C[aspacem_maxAddr = sp_at_startup - 1]
    B -- Yes --> D{VGP_amd64_linux?}
    D -- Yes --> E[aspacem_maxAddr = 1 TiB - 1]
    D -- No --> F[aspacem_maxAddr = 128 GiB - 1]
    E --> G{ENABLE_INNER?}
    F --> G
    G -- Yes --> H[Cap at VG_PGROUNDDN sp_at_startup - 1]
    G -- No --> I[Keep value as-is]
    H --> J[aspacem_vStart = midpoint]
    I --> J
    J --> K[amd64_linux: vStart ~512 GiB / client hole ~512 GiB]
Loading
%%{init: {'theme': 'base', 'themeVariables': {"darkMode": true, "background": "#0d1117", "primaryColor": "#21262d", "primaryTextColor": "#e6edf3", "primaryBorderColor": "#8b949e", "lineColor": "#8b949e", "textColor": "#e6edf3", "edgeLabelBackground": "#161b22", "actorBkg": "#21262d", "actorBorder": "#8b949e", "actorTextColor": "#e6edf3", "actorLineColor": "#8b949e", "signalColor": "#8b949e", "signalTextColor": "#e6edf3", "noteBkgColor": "#373320", "noteBorderColor": "#d4a72c", "noteTextColor": "#f0e6c0", "labelBoxBkgColor": "#21262d", "labelBoxBorderColor": "#8b949e", "labelTextColor": "#e6edf3", "loopTextColor": "#e6edf3", "activationBkgColor": "#30363d", "activationBorderColor": "#8b949e"}}}%%
flowchart TD
    A[VG_am_startup called] --> B{VG_WORDSIZE == 8?}
    B -- No --> C[aspacem_maxAddr = sp_at_startup - 1]
    B -- Yes --> D{VGP_amd64_linux?}
    D -- Yes --> E[aspacem_maxAddr = 1 TiB - 1]
    D -- No --> F[aspacem_maxAddr = 128 GiB - 1]
    E --> G{ENABLE_INNER?}
    F --> G
    G -- Yes --> H[Cap at VG_PGROUNDDN sp_at_startup - 1]
    G -- No --> I[Keep value as-is]
    H --> J[aspacem_vStart = midpoint]
    I --> J
    J --> K[amd64_linux: vStart ~512 GiB / client hole ~512 GiB]
Loading

Reviews (1): Last reviewed commit: "fix(aspacem): raise amd64 managed addres..." | Re-trigger Greptile

@codspeed-hq

codspeed-hq Bot commented Jul 6, 2026

Copy link
Copy Markdown

Merging this PR will not alter performance

✅ 42 untouched benchmarks
⏩ 88 skipped benchmarks1


Comparing cod-3073-investigate-valgrind-support-for-snmallocs-256-gib (5714dad) with master (ce9d871)

Open in CodSpeed

Footnotes

  1. 88 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports.

@not-matthias not-matthias marked this pull request as ready for review July 6, 2026 13:11
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants