qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v6 00/15] RAM_NORESERVE, MAP_NORESERVE and hostmem "reserve"


From: Eduardo Habkost
Subject: Re: [PATCH v6 00/15] RAM_NORESERVE, MAP_NORESERVE and hostmem "reserve" property
Date: Wed, 21 Apr 2021 17:06:11 -0400

On Wed, Apr 21, 2021 at 02:26:09PM +0200, David Hildenbrand wrote:
> Based-on: 20210406080126.24010-1-david@redhat.com
> 
> Some cleanups previously sent in other context (resizeable allocations),
> followed by RAM_NORESERVE, implementing it under Linux 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/shared anonymous memory
> -> memory-backend-ram,id=mem0,size=10G
> 2) Private fd-based mappings
> -> memory-backend-file,id=mem0,size=10G,mem-path=/dev/shm/0
> -> memory-backend-memfd,id=mem0,size=10G
> 3) Private/shared hugetlb mappings
> -> 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 having to set "/proc/sys/vm/overcommit_memory == 1") when using
> virtio-mem and also supporting hugetlbfs in the future.

For the memory backend and machine core code:

Acked-by: Eduardo Habkost <ehabkost@redhat.com>

-- 
Eduardo




reply via email to

[Prev in Thread] Current Thread [Next in Thread]