Some cleanups previously sent in other context (resizeable allocations),
followed by RAM_NORESERVE, implementing it under POSIX using MAP_NORESERVE,
and letting users configure it for memory backens using the "reserve"
property (default: true).
MAP_NORESERVE under Linux has in the context of QEMU an effect on
1) Private anonymous memory
-> memory-backend-ram,id=mem0,size=10G
2) Private file-based mappings
-> memory-backend-file,id=mem0,size=10G,mem-path=/dev/shm/0
3) Private/shared hugetlbfs memory
-> memory-backend-memfd,id=mem0,size=10G,hugetlb=on,hugetlbsize=2M
With MAP_NORESERVE/"reserve=off", we won't be reserving swap space (1/2) or
huge pages (3) for the whole memory region.
The target use case is virtio-mem, which dynamically exposes memory
inside a large, sparse memory area to the VM. MAP_NORESERVE tells the OS
"this mapping might be very sparse". This essentially allows
avoiding to set "/proc/sys/vm/overcommit_memory == 0") when using
virtio-mem and also supporting hugetlbfs in the future.
virtio-mem currently only supports anonymous memory, in the future we want
to also support shared file-based and shared hugetlbfs mappings. We most
probably won't be supporting private mappings as they can end up behaving
very weird when it comes to memory consumption.
Future work for virtio-mem I am currently working on includes
1. Introducing a prealloc option for virtio-mem (e.g., using fallocate()
when plugging blocks) to fail nicely when running out of
backing storage like huge pages.
2. Supporting resizable RAM block/memoryr egions, such that we won't always
expose a large, sparse memory region to the VM.
3. Protecting unplugged memory e.g., using userfaultfd.
4. (resizeable allocations / optimized mmap handling when resizing RAM
blocks)