[LLVM] Fix JITLink excessive VMA count on AArch64#61418
Open
alecloudenback wants to merge 1 commit intoJuliaLang:masterfrom
Open
[LLVM] Fix JITLink excessive VMA count on AArch64#61418alecloudenback wants to merge 1 commit intoJuliaLang:masterfrom
alecloudenback wants to merge 1 commit intoJuliaLang:masterfrom
Conversation
MapperJITLinkMemoryManager previously used a single memory pool for all allocations regardless of protection flags. This caused each allocation's segments (typically RX for code, RW for data) to be interleaved in the address space, creating a new VMA at every permission boundary. With many JIT allocations this exceeded Linux's default vm.max_map_count of 65530. This patch introduces per-MemProt memory pools so that pages with the same protection flags are allocated from contiguous address ranges. The kernel coalesces adjacent same-permission pages into single VMAs. Additionally, InProcessMemoryMapper::Allocation now tracks individual segment ranges instead of a single min-max span, so that deinitialize() resets permissions precisely per-segment rather than over a span that could cover unrelated allocations. Measurements on AArch64 with LinearAlgebra workload: - Unpatched Julia 1.12.5: 641 added VMAs - Patched Julia 1.12.0: 5 added VMAs (128x reduction) Upstream LLVM issue: llvm/llvm-project#63236 Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Member
|
I expect this to cause problems when the region starts to fill up (see #60915, and the referenced earlier PRs that were merged and reverted). |
Member
|
As a matter of procedure, right now the patch is not tested in CI, since CI uses the prebuilt binaries from Yggdrasil. Additionally, it would be great to have this patch land first in LLVM upstream (or at least be discussed there first) |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
MapperJITLinkMemoryManagernow uses per-MemProtmemory pools so same-permission pages are contiguous, allowing the kernel to coalesce VMAsInProcessMemoryMappernow tracks per-segment ranges for precise deinitialization instead of a single min-max spanFixes llvm/llvm-project#63236
Problem
JITLink's
MapperJITLinkMemoryManageruses a single memory pool for all allocations. Each allocation's segments (RX for code, RW for data) get interleaved:[RX1][RW1][RX2][RW2].... Every permission boundary creates a new VMA in the Linux kernel. With thousands of JIT allocations (e.g., loading LinearAlgebra), this can exceed the defaultvm.max_map_countof 65530, causingENOMEM("Cannot allocate memory") errors.The current workaround is
sysctl -w vm.max_map_count=262144, documented in Julia's AArch64 platform notes.Fix
Per-
MemProtmemory pools ensure same-permission pages cluster together:[RX1][RX2]...[RW1][RW2].... The kernel coalesces these into just a few VMAs regardless of allocation count.Measurements (AArch64)
using LinearAlgebra+ light LATest plan
vm.max_map_count=65530Generated with Claude Code