cocoon #127 + the CH fork's mmap restore mode (cocoonstack/cloud-hypervisor, pending merge) let clones of one snapshot CoW-map the memory file and share page cache. Full-stack A/B on the bench host (throwaway sandboxd @6615de0 with an env-gated flag, CH egress medium golden-only pool, 2 rounds each):
| metric |
copy |
mmap |
| sequential clone p50 |
107.3 ms |
80.2 ms (−25%) |
| burst16 per-claim p50 |
956 / 744 ms |
318 / 243 ms (−67%) |
| burst16 wall |
1284 / 1045 ms |
613 / 491 ms (−53%) |
CH-level isolation (fork commit): burst16 wall 456–478 → 87–108 ms; the full-stack delta is smaller because claim-path fixed costs (nft lane lock, probe, HTTP) don't shrink.
Wiring: engine.cloneArgs appends --restore-mode mmap for net=egress keys (CH lane; the FC lane's restore already mmaps and cocoon's flag is CH-only), behind a config knob (restore_mode, default off).
Gate before flipping anywhere: an older CH has no memory_restore_mode field and silently ignores it (serde), restoring by copy while reporting success (documented in cocoon #127) — the knob must stay opt-in until the fleet carries a CH build with the fork's mmap commit; there is no version probe on the clone hot path by design.
Invariant audit (done): mmap requires the snapshot memory file unchanged on disk for the VM lifetime. sandboxd's golden lifecycle already satisfies it — goldens are immutable dirs replaced atomically (RemoveAll+rename = new inode; unlink keeps the mapped inode alive), never edited in place; and the egress lane forbids hibernate/fork/checkpoint/promote, so mmap-restored clones only ever run and release.
Hot-path cost: negative on the CH clone path; zero elsewhere.
Acceptance: egresssmoke + intercept-e2e green with the knob on; the A/B numbers reproduced via the bench burst stage against an egress pool; explicit old-CH test documenting the silent-copy fallback behavior.
cocoon #127 + the CH fork's mmap restore mode (cocoonstack/cloud-hypervisor, pending merge) let clones of one snapshot CoW-map the memory file and share page cache. Full-stack A/B on the bench host (throwaway sandboxd @6615de0 with an env-gated flag, CH egress medium golden-only pool, 2 rounds each):
CH-level isolation (fork commit): burst16 wall 456–478 → 87–108 ms; the full-stack delta is smaller because claim-path fixed costs (nft lane lock, probe, HTTP) don't shrink.
Wiring:
engine.cloneArgsappends--restore-mode mmapfornet=egresskeys (CH lane; the FC lane's restore already mmaps and cocoon's flag is CH-only), behind a config knob (restore_mode, default off).Gate before flipping anywhere: an older CH has no
memory_restore_modefield and silently ignores it (serde), restoring by copy while reporting success (documented in cocoon #127) — the knob must stay opt-in until the fleet carries a CH build with the fork's mmap commit; there is no version probe on the clone hot path by design.Invariant audit (done): mmap requires the snapshot memory file unchanged on disk for the VM lifetime. sandboxd's golden lifecycle already satisfies it — goldens are immutable dirs replaced atomically (RemoveAll+rename = new inode; unlink keeps the mapped inode alive), never edited in place; and the egress lane forbids hibernate/fork/checkpoint/promote, so mmap-restored clones only ever run and release.
Hot-path cost: negative on the CH clone path; zero elsewhere.
Acceptance: egresssmoke + intercept-e2e green with the knob on; the A/B numbers reproduced via the bench burst stage against an egress pool; explicit old-CH test documenting the silent-copy fallback behavior.