On 09.02.21 14:49, David Hildenbrand wrote:
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)
Ping -- Thanks, David / dhildenb
