vm: mergeable guest memory for host KSM dedup - #191
Merged
Conversation
CH madvises guest memory MADV_MERGEABLE with --memory mergeable=on; cocoon never passed it, so KSM could not reach VM pages. Opt-in at create (--mergeable), persists through snapshot/clone/restore via the snapshot's CH config. Excludes hugepages/shared memory (KSM merges only plain private pages); FC rejects the flag. Enabling and tuning the KSM scanner stays host-side operator policy.
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.
CH already supports
--memory ...,mergeable=on(madviseMADV_MERGEABLEon guest memory); cocoon never passed it, so host KSM had zero reachable candidates in VM memory regardless of host tuning. This wires it through as an opt-in create-time flag.Semantics, mirroring
--hugepages/--shared-memory:--mergeableonvm run/vm create, fixed for the VM lifetime; recorded intypes.Config, so it rides the snapshot's CHconfig.jsonand clones/restores inherit it with no CLI involvement — build the golden with it (or rebuild)--hugepages/--shared-memory: KSM merges only plain private pages, the combo would silently dedup nothing; guarded once inVMConfigFromFlags, the only place the combo can originatevalidateBackendFlagsfast-fail (create + debug paths) and the backend-owned check infirecracker/create.go/sys/kernel/mm/ksm/*) stays host-side operator policy--memoryvalue building is now shared between launch andvm debug(DebugMemoryCLIArg, same pattern asDebugDiskCLIArgs), so the printed command can't drift from the real oneAcceptance on a 384-core host (fork dev CH, checksum-verified):
--mergeable --hugepages→--mergeable needs plain private memory; drop --hugepages/--shared-memory--fc --mergeable→ fast-fail--fc and --mergeable are mutually exclusive: Firecracker has no KSM madvise knob--memory size=2147483648,mergeable=onconfig.jsoncarries"mergeable":true; both flag-less clones' run-dir configs show it (2 "mergeable":true)pages_sharing0 → 342k pages (~1.34 GB deduplicated) within 20spages_sharingstays 0 (the madvise is the sole gate)run=0,pages_to_scan=100,sharing=0)Gates:
make lint(both GOOS) 0 issues,asl ./...(both GOOS) clean,go test ./...green; newTestMemoryCLIArgcovers the memory kv for plain/hugepages+shared/mergeable.Density measurement at fleet scale is deliberately out of scope here — mmap siblings already share untouched pages via the page cache, so KSM's marginal gain (dirtied-but-equal + cross-golden pages) needs measuring on the real workload; the doc note says so.