[luke-lombardi]

Restoring CUDA checkpoints advised huge pages even when the destination host policy had disabled them. On the affected host this caused direct compaction while loading and pinning restored memory. Honor the existing immutable ExpectHugepages policy at both advice sites, retaining eager page loading, writable prefaulting and CUDA pinning.

Use eight 4 MiB page reads instead of 128 256 KiB reads, keeping 32 MiB in flight. Writer defaults, read limits, short-read/error handling and serialized checkpoint fields remain unchanged.

The optional artifact-build input preserves ebbaed3f9dd5 for this state-compatible hotfix. Both strict checkpoint-version checks remain enabled, and the worker's runtime-version fingerprint input is unchanged. Identify the artifact by its new source revision, immutable release tag and SHA512; default builds retain their existing git-described version behavior.

Validation: the canonical Linux artifact restored the original, unmodified owned VoxCPM2 checkpoint with retained nonce and identical audio. Final runtime durations were 13.56–14.34s on the affected host and 11.64–13.24s on the control host; one corresponding deployed control took 19.31s with 12.28s in prefault versus 4.03–4.65s for the candidate. Registered host memory, GPU allocations, module and stream state also passed. Profiling demonstrated direct compaction in deployed restores and none in the policy-guard cases.

These private runtime measurements exclude scheduling and checkpoint transfer. Some warmed deployed restores were faster, and the reader change's independent full-model benefit is not established; this addresses compaction stalls rather than guaranteeing every restore is faster. No production runtime was replaced during validation.

[jackf-beamcloud]

Looks right: the ExpectHugepages guard in adviseHugepageRanges covers both callers (AdviseHugepageRanges and PrefaultRanges), the reader default change only affects restore reads (writer and NewPagesFileFDReader callers untouched), and the checkpoint_version input is passed via env and regex-checked before reaching the shell, so no injection. Non-blocking: guarding on ExpectHugepages rather than AdviseHugepage means a host that expects THP but has advice disabled will still madvise here; fine if that's intended, maybe worth a comment.

[luke-lombardi]

Using ExpectHugepages is intentional. It is the loader's decision whether huge pages are permitted; AdviseHugepage controls advice for ordinary allocations and remains false for shmem_enabled=always, within_size and force. This guard preserves the previous CUDA preparation on those permitted policies and changes only hosts where the loader selected small pages. I kept the patch limited to that policy correction.