vmm: Revert "vmm: create memfd for private mappings" - #8246
Merged
rbradford merged 1 commit intoMay 18, 2026
Merged
Conversation
This reverts commit ced3762. This change lead to a serious memory regression when not using hugepages or shared=on. `MAP_PRIVATE` creates an anonymous memory allocation for every page written when the backing store is a file. This CoW behaviour is useful but leads to double allocations when the backing store is an empty file created by `memfd_create()`. When the page is written to, the CoW semantics require a real page to be created in the memory for the memfd (previously before the page was touched they would all point to the zero page). This real page is filled with zeroes because in theory this page would be accessible via read/write syscalls on the FD even though in our implementation it is only ever `mmap()`ed. The intention of the commit was to enable `fallocate()` to be used to punch holes but that would only affect the inaccessible backing page and the page in the CoW anonymous memory would be unaffected. Leading it likely not to have the desired effect. Fixes: cloud-hypervisor#8211 Signed-off-by: Rob Bradford <[email protected]>
Member
Author
|
I also considered fixing it by using |
Member
Author
|
@phip1611 It's strange how this didn't affect the Windows runs on the PR itself or later ones. Nor was it picked up by the |
rbradford
enabled auto-merge
May 18, 2026 12:43
weltling
approved these changes
May 18, 2026
weltling
left a comment
Member
There was a problem hiding this comment.
I've been experimenting with this for several hours, too. The OOM symptom
could be fixed by readding MAP_ANONYMOUS, but that would undermine the initial intention for fallocate. The behaviors probably need to be tied to the console options, so then corresponding flags combinations would be used.
Thanks!
3 tasks
github-merge-queue
Bot
removed this pull request from the merge queue due to no response for status checks
May 18, 2026
3 tasks
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
3 participants
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.
This reverts commit ced3762.
This change lead to a serious memory regression when not using hugepages
or shared=on.
MAP_PRIVATEcreates an anonymous memory allocation for every pagewritten when the backing store is a file. This CoW behaviour is useful
but leads to double allocations when the backing store is an empty file
created by
memfd_create(). When the page is written to, the CoWsemantics require a real page to be created in the memory for the memfd
(previously before the page was touched they would all point to the zero
page). This real page is filled with zeroes because in theory this page
would be accessible via read/write syscalls on the FD even though in our
implementation it is only ever
mmap()ed.The intention of the commit was to enable
fallocate()to be used topunch holes but that would only affect the inaccessible backing page and
the page in the CoW anonymous memory would be unaffected. Leading it
likely not to have the desired effect.
Fixes: #8211
Signed-off-by: Rob Bradford [email protected]