Uh oh!
There was an error while loading.Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork34k
gh-144319: Fix huge page safety in pymalloc arenas#144331
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to ourterms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
Conversation
The pymalloc huge page support had two problems. First, onarchitectures where the default huge page size exceeds the arenasize (e.g. 32 MiB on PPC, 512 MiB on ARM64 with 64 KB basepages), mmap with MAP_HUGETLB silently allocates a full huge pageeven when the requested size is smaller. The subsequent munmapwith the original arena size then fails with EINVAL, permanentlyleaking the entire huge page. Second, huge pages were alwaysattempted when compiled in, with no way to disable them atruntime. On Linux, if the huge page pool is exhausted, pagefaults including copy-on-write faults after fork deliver SIGBUSand 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 amultiple of it. Huge pages also now require explicit opt-in atruntime 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 runtimeallocators struct so the low-level arena allocator can check itwithout calling getenv directly.
vstinner left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
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.
Uh oh!
There was an error while loading.Please reload this page.
Co-authored-by: Victor Stinner <vstinner@python.org>
pablogsal commentedJan 30, 2026
Thanks! Yeah we plan to do 2MiB |
96e4cd6 intopython:mainUh oh!
There was an error while loading.Please reload this page.
Uh oh!
There was an error while loading.Please reload this page.
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/