Advise MADV_HUGEPAGE independently of allow_large#1328
Open
rui314 wants to merge 1 commit into
Open
Conversation
The THP advise was gated on the caller's allow_large parameter, which callers derive from segment laziness and which primarily exists to gate MAP_HUGETLB. hugetlbfs pages are physically committed at map time, so keeping them away from lazily-committed segments makes sense, but transparent huge pages materialize on fault and have no such cost. As a result of sharing the gate, huge objects (the OS singleton path) and each thread's first segment were never eligible for THP under Linux's madvise THP mode even with allow_thp enabled. With this change the advise depends only on the allow_thp option, matching the effective behavior of the dev3 branch, where singleton pages are committed eagerly and allow_large no longer depends on laziness. In the mold linker, whose largest data structures allocate through the huge-object path, this makes linking a Chromium debug build about 2% faster (3.37s to 3.29s) on a 64-core machine, and 15% faster (4.05s to 3.43s) when mold runs in its single-process mode, where the process exit cost is user-visible and freeing a heap of 2 MiB folios is much cheaper than freeing millions of 4 KiB folios. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
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
1 participant
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.
On Linux with the default distro THP setting (
madvise), memory becomes eligible for transparent huge pages only if the process callsmadvise(MADV_HUGEPAGE)on it. mimalloc gates that advise on the caller'sallow_largeparameter, which callers derive from segment laziness and which primarily exists to gateMAP_HUGETLB. Thehugetlbfs half of that gate makes sense (hugetlb pages are physically committed at map time), but THP pages materialize on fault, so tying the two together means huge objects (the OS singleton path) and each thread's first segment are never THP-eligible even with
MIMALLOC_ALLOW_THP=1, which is the default.This PR makes the advise depend only on
mi_option_allow_thp, leaving the hugetlbfs gate unchanged. dev3 effectively behaves this way already (singleton pages are committed eagerly andallow_largeno longer depends on laziness), so this can be seen as aligning dev2 with dev3 semantics.Motivating case: in the mold linker, the largest data structures (multi-gigabyte symbol and relocation arrays) allocate through the huge-object path. On a Chromium debug link, about 5.7 GiB of a 14.5 GiB heap stayed on 4 KiB pages; with this change the heap is almost fully huge-page backed, linking is about 2% faster in mold's default mode and 15% faster in its single-process mode, where process exit is user-visible and tearing down 2 MiB folios is far cheaper than millions of 4 KiB folios.