Repository navigation
gh-144319: Fix huge page safety in pymalloc arenas - #144331
Merged
pablogsal merged 2 commits intoJan 30, 2026
Merged
pablogsal merged 2 commits into
pablogsal merged 2 commits into
Conversation
Copy link
Copy Markdown
Member
Sorry, something went wrong.
pablogsal
requested review from
AA-Turner,
corona10,
emmatyping,
ericsnowcurrently and
erlend-aasland
as code owners
January 29, 2026 21:52
The pymalloc huge page support had two problems. First, on architectures where the default huge page size exceeds the arena size (e.g. 32 MiB on PPC, 512 MiB on ARM64 with 64 KB base pages), mmap with MAP_HUGETLB silently allocates a full huge page even when the requested size is smaller. The subsequent munmap with the original arena size then fails with EINVAL, permanently leaking the entire huge page. Second, huge pages were always attempted when compiled in, with no way to disable them at runtime. On Linux, if the huge page pool is exhausted, page faults including copy-on-write faults after fork deliver SIGBUS and kill the process. The arena allocator now queries the system huge page size from /proc/meminfo and skips MAP_HUGETLB when the arena size is not a multiple of it. Huge pages also now require explicit opt-in at runtime via the PYTHON_PYMALLOC_HUGEPAGES environment variable, which is read through PyConfig and respects -E and -I flags. The config field pymalloc_hugepages is propagated to the runtime allocators struct so the low-level arena allocator can check it without calling getenv directly.
pablogsal
force-pushed
the
gh-144319-2
branch
from
178824b to
9b10013
Compare
January 29, 2026 22:58
vstinner
reviewed
Jan 30, 2026
vstinner
left a comment
Copy link
Copy Markdown
Member
There was a problem hiding this comment.
LGTM.
Since huge pages are no longer used by default, even if PYMALLOC_USE_HUGEPAGES macro is defined, maybe you can consider removing PYMALLOC_USE_HUGEPAGES macro in a following PR. That would require to change ARENA_BITS to 21 (2 MiB) by default.
Sorry, something went wrong.
Comment thread
Doc/using/cmdline.rst
Outdated
Co-authored-by: Victor Stinner <vstinner@python.org>
Copy link
Copy Markdown
Member
Author
Thanks! Yeah we plan to do 2MiB ARENA_BITS by default in a different PR so this looks like a great addition! |
Sorry, something went wrong.
thunder-coding
pushed a commit
to thunder-coding/cpython
that referenced
this pull request
Feb 15, 2026
The pymalloc huge page support had two problems. First, on architectures where the default huge page size exceeds the arena size (e.g. 32 MiB on PPC, 512 MiB on ARM64 with 64 KB base pages), mmap with MAP_HUGETLB silently allocates a full huge page even when the requested size is smaller. The subsequent munmap with the original arena size then fails with EINVAL, permanently leaking the entire huge page. Second, huge pages were always attempted when compiled in, with no way to disable them at runtime. On Linux, if the huge page pool is exhausted, page faults including copy-on-write faults after fork deliver SIGBUS and kill the process. The arena allocator now queries the system huge page size from /proc/meminfo and skips MAP_HUGETLB when the arena size is not a multiple of it. Huge pages also now require explicit opt-in at runtime via the PYTHON_PYMALLOC_HUGEPAGES environment variable, which is read through PyConfig and respects -E and -I flags. The config field pymalloc_hugepages is propagated to the runtime allocators struct so the low-level arena allocator can check it without calling getenv directly.
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
Reviewers
2 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.
The pymalloc huge page support had two problems. First, on
architectures where the default huge page size exceeds the arena
size (e.g. 32 MiB on PPC, 512 MiB on ARM64 with 64 KB base
pages), mmap with MAP_HUGETLB silently allocates a full huge page
even when the requested size is smaller. The subsequent munmap
with the original arena size then fails with EINVAL, permanently
leaking the entire huge page. Second, huge pages were always
attempted when compiled in, with no way to disable them at
runtime. On Linux, if the huge page pool is exhausted, page
faults including copy-on-write faults after fork deliver SIGBUS
and kill the process.
The arena allocator now queries the system huge page size from
/proc/meminfo and skips MAP_HUGETLB when the arena size is not a
multiple of it. Huge pages also now require explicit opt-in at
runtime via the PYTHON_PYMALLOC_HUGEPAGES environment variable,
which is read through PyConfig and respects -E and -I flags.
📚 Documentation preview 📚: https://cpython-previews--144331.org.readthedocs.build/