From: Eduardo Habkost <ehabkost@redhat.com>
To: David Hildenbrand <david@redhat.com>
Cc: "Thomas Huth" <thuth@redhat.com>,
"Cornelia Huck" <cohuck@redhat.com>,
"Juan Quintela" <quintela@redhat.com>,
"Michael S. Tsirkin" <mst@redhat.com>,
"Stefan Weil" <sw@weilnetz.de>,
"Murilo Opsfelder Araujo" <muriloo@linux.ibm.com>,
"Richard Henderson" <richard.henderson@linaro.org>,
"Dr. David Alan Gilbert" <dgilbert@redhat.com>,
"Peter Xu" <peterx@redhat.com>,
qemu-devel@nongnu.org, "Halil Pasic" <pasic@linux.ibm.com>,
"Christian Borntraeger" <borntraeger@de.ibm.com>,
"Greg Kurz" <groug@kaod.org>,
"Stefan Hajnoczi" <stefanha@redhat.com>,
"Igor Mammedov" <imammedo@redhat.com>,
"Paolo Bonzini" <pbonzini@redhat.com>,
"Philippe Mathieu-Daudé" <philmd@redhat.com>,
"Igor Kotrasinski" <i.kotrasinsk@partner.samsung.com>
Subject: Re: [PATCH v2 9/9] hostmem: Wire up RAM_NORESERVE via "reserve" property
Date: Fri, 5 Mar 2021 17:14:31 -0500 [thread overview]
Message-ID: <20210305221431.GG3139005@habkost.net> (raw)
In-Reply-To: <20210305101634.10745-10-david@redhat.com>
On Fri, Mar 05, 2021 at 11:16:34AM +0100, David Hildenbrand wrote:
> Let's provide a way to control the use of RAM_NORESERVE via memory
> backends using the "reserve" property which defaults to true (old
> behavior).
>
> Only POSIX supports setting the flag (and Linux support is checked at
> runtime, depending on the setting of "/proc/sys/vm/overcommit_memory").
> Windows will bail out.
>
> The target use case is virtio-mem, which dynamically exposes memory
> inside a large, sparse memory area to the VM. This essentially allows
> avoiding to set "/proc/sys/vm/overcommit_memory == 0") when using
> virtio-mem and also supporting hugetlbfs in the future.
>
> Reviewed-by: Peter Xu <peterx@redhat.com>
> Signed-off-by: David Hildenbrand <david@redhat.com>
Reviewed-by: Eduardo Habkost <ehabkost@redhat.com>
Paolo, will the whole series get through your memory API queue?
Also, do you think we should move backends/hostmem* under the
"memory API" section in MAINTAINERS? Most memory backend changes
also involve changes in the memory API.
--
Eduardo
prev parent reply other threads:[~2021-03-05 22:16 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-05 10:16 [PATCH v2 0/9] RAM_NORESERVE, MAP_NORESERVE and hostmem "reserve" property David Hildenbrand
2021-03-05 10:16 ` [PATCH v2 1/9] softmmu/physmem: Drop "shared" parameter from ram_block_add() David Hildenbrand
2021-03-05 10:16 ` [PATCH v2 2/9] util/mmap-alloc: Factor out calculation of the pagesize for the guard page David Hildenbrand
2021-03-05 10:16 ` [PATCH v2 3/9] util/mmap-alloc: Factor out reserving of a memory region to mmap_reserve() David Hildenbrand
2021-03-05 10:16 ` [PATCH v2 4/9] util/mmap-alloc: Factor out activating of memory to mmap_activate() David Hildenbrand
2021-03-05 10:16 ` [PATCH v2 5/9] softmmu/memory: Pass ram_flags into qemu_ram_alloc_from_fd() David Hildenbrand
2021-03-05 10:16 ` [PATCH v2 6/9] softmmu/memory: Pass ram_flags into memory_region_init_ram_shared_nomigrate() David Hildenbrand
2021-03-05 10:16 ` [PATCH v2 7/9] memory: introduce RAM_NORESERVE and wire it up in qemu_ram_mmap() David Hildenbrand
2021-03-05 10:16 ` David Hildenbrand
2021-03-05 15:37 ` Peter Xu
2021-03-05 15:37 ` Peter Xu
2021-03-05 10:16 ` [PATCH v2 8/9] util/mmap-alloc: Support RAM_NORESERVE via MAP_NORESERVE David Hildenbrand
2021-03-05 15:42 ` Peter Xu
2021-03-05 15:44 ` David Hildenbrand
2021-03-05 15:51 ` Peter Xu
2021-03-05 16:24 ` David Hildenbrand
2021-03-07 13:18 ` David Hildenbrand
2021-03-07 14:11 ` Marcel Apfelbaum
2021-03-08 8:45 ` David Hildenbrand
2021-03-08 8:54 ` Marcel Apfelbaum
2021-03-05 10:16 ` [PATCH v2 9/9] hostmem: Wire up RAM_NORESERVE via "reserve" property David Hildenbrand
2021-03-05 22:14 ` Eduardo Habkost [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20210305221431.GG3139005@habkost.net \
--to=ehabkost@redhat.com \
--cc=borntraeger@de.ibm.com \
--cc=cohuck@redhat.com \
--cc=david@redhat.com \
--cc=dgilbert@redhat.com \
--cc=groug@kaod.org \
--cc=i.kotrasinsk@partner.samsung.com \
--cc=imammedo@redhat.com \
--cc=mst@redhat.com \
--cc=muriloo@linux.ibm.com \
--cc=pasic@linux.ibm.com \
--cc=pbonzini@redhat.com \
--cc=peterx@redhat.com \
--cc=philmd@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=quintela@redhat.com \
--cc=richard.henderson@linaro.org \
--cc=stefanha@redhat.com \
--cc=sw@weilnetz.de \
--cc=thuth@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.