gh-144319: Fix huge page safety in pymalloc arenas #144331
Merged
Conversation
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
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.
178824b to
9b10013
Compare
vstinner
reviewed
Jan 30, 2026
Member
vstinner
left a comment
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.
Co-authored-by: Victor Stinner <[email protected]>
Member
Author
Thanks! Yeah we plan to do 2MiB |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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/