Repository navigation
feat(os): build transparent huge pages into the guest kernel, default madvise - #1503
Merged
Merged
Conversation
… madvise Neither guest kernel has CONFIG_TRANSPARENT_HUGEPAGE, so every guest mapping is backed by 4 KiB pages. In a CVM a TLB miss walks the guest page tables with every level translated through the host's (secure) EPT, which makes 4 KiB pages expensive for workloads with a large hot working set. On a B200 TDX guest over 2 MiB EPT, guest 2 MiB pages took a pointer chase from 112 to 81 ns (256 MiB) and from 288 to 246 ns (16 GiB), brought Python/torch CPU microbenchmarks to bare-metal level, and let SGLang move its ~2.5 GiB of scheduler code onto huge pages, saving ~0.4 ms per decode step. The sysfs default is madvise: only regions marked MADV_HUGEPAGE get huge pages, so workloads that do not ask see no change, and THP's memory bloat and fault-time compaction stay opt-in. A workload that wants THP for everything writes "always" to /sys/kernel/mm/transparent_hugepage/enabled at runtime instead of adding transparent_hugepage= to the measured kernel command line. Added to both backends and asserted in parity.json. Signed-off-by: Kevin Wang <wy721@qq.com>
kvinwang
force-pushed
the
feat/guest-thp
branch
from
October 30, 2026 00:34
ff5a0ff to
2fc4caa
Compare
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
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.
Neither guest kernel has
CONFIG_TRANSPARENT_HUGEPAGE, so all guest memory is mapped with 4 KiB pages. In a CVM each level of a guest page walk is itself translated through the secure EPT, so 4 KiB pages hurt workloads with a large hot working set.This adds
CONFIG_TRANSPARENT_HUGEPAGE=ywith the sysfs defaultmadviseto both backends, and asserts it inparity.json. Only regions markedMADV_HUGEPAGEget huge pages, so other workloads see no change. A workload that wants THP everywhere writesalwaysto/sys/kernel/mm/transparent_hugepage/enabledat runtime. The measured kernel command line is unchanged.Measured on a B200 TDX guest (host with 2 MiB secure-EPT mappings, guest 6.18.40 + THP):
MADV_HUGEPAGEmemory, saving ~0.4 ms per decode step.Testing:
make os-image(mkosi repro build) passes, includingcheck-kernel-config.shand the parity check..confighasTRANSPARENT_HUGEPAGE=yandTRANSPARENT_HUGEPAGE_MADVISE=y.