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

[Eduardo Habkost]

On Fri, Apr 23, 2021 at 12:35:35PM +0200, David Hildenbrand wrote:
> On 21.04.21 23:06, Eduardo Habkost wrote:
> > 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>
> > 
> 
> Thanks Eduardo. I assume Paolo will be the right maintainer to pick this up?
> (I hope he'll have time to look at this and some of my
> pending-for-a-long-time series soon :( )

I can pick it up (or you could merge it through your tree if you
prefer), but I would like to get at least an Acked-by from Paolo
first.

On the other hand, maybe v7 is mature enough to not require
waiting too much longer.

-- 
Eduardo