All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Hildenbrand <david@redhat.com>
To: Markus Armbruster <armbru@redhat.com>
Cc: "Marcel Apfelbaum" <mapfelba@redhat.com>,
	"Eduardo Habkost" <ehabkost@redhat.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	"Richard Henderson" <richard.henderson@linaro.org>,
	qemu-devel@nongnu.org, "Peter Xu" <peterx@redhat.com>,
	"Dr. David Alan Gilbert" <dgilbert@redhat.com>,
	"Greg Kurz" <groug@kaod.org>,
	"Stefan Hajnoczi" <stefanha@redhat.com>,
	"Murilo Opsfelder Araujo" <muriloo@linux.ibm.com>,
	"Paolo Bonzini" <pbonzini@redhat.com>,
	"Philippe Mathieu-Daudé" <philmd@redhat.com>,
	"Igor Mammedov" <imammedo@redhat.com>
Subject: Re: [PATCH v6 14/15] qmp: Include "reserve" property of memory backends
Date: Fri, 23 Apr 2021 13:33:20 +0200	[thread overview]
Message-ID: <79cdbd39-cf5c-a8ab-b2c9-68d8e4ab2333@redhat.com> (raw)
In-Reply-To: <87h7jxgsa0.fsf@dusky.pond.sub.org>

On 23.04.21 13:21, Markus Armbruster wrote:
> David Hildenbrand <david@redhat.com> writes:
> 
>> On 23.04.21 13:00, Markus Armbruster wrote:
>>> David Hildenbrand <david@redhat.com> writes:
>>>
>>>> Let's include the new property.
>>>>
>>>> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
>>>> Cc: Eric Blake <eblake@redhat.com>
>>>> Cc: Markus Armbruster <armbru@redhat.com>
>>>> Cc: Igor Mammedov <imammedo@redhat.com>
>>>> Signed-off-by: David Hildenbrand <david@redhat.com>
>>>> ---
>>>>    hw/core/machine-qmp-cmds.c | 1 +
>>>>    qapi/machine.json          | 4 ++++
>>>>    2 files changed, 5 insertions(+)
>>>>
>>>> diff --git a/hw/core/machine-qmp-cmds.c b/hw/core/machine-qmp-cmds.c
>>>> index d41db5b93b..2d135ecdd0 100644
>>>> --- a/hw/core/machine-qmp-cmds.c
>>>> +++ b/hw/core/machine-qmp-cmds.c
>>>> @@ -175,6 +175,7 @@ static int query_memdev(Object *obj, void *opaque)
>>>>            m->dump = object_property_get_bool(obj, "dump", &error_abort);
>>>>            m->prealloc = object_property_get_bool(obj, "prealloc", &error_abort);
>>>>            m->share = object_property_get_bool(obj, "share", &error_abort);
>>>> +        m->reserve = object_property_get_bool(obj, "reserve", &error_abort);
>>>>            m->policy = object_property_get_enum(obj, "policy", "HostMemPolicy",
>>>>                                                 &error_abort);
>>>>            host_nodes = object_property_get_qobject(obj,
>>>> diff --git a/qapi/machine.json b/qapi/machine.json
>>>> index 32650bfe9e..5932139d20 100644
>>>> --- a/qapi/machine.json
>>>> +++ b/qapi/machine.json
>>>> @@ -798,6 +798,9 @@
>>>>    #
>>>>    # @share: whether memory is private to QEMU or shared (since 6.1)
>>>>    #
>>>> +# @reserve: whether swap space (or huge pages) was reserved if applicable
>>>> +#           (since 6.1)
>>>> +#
>>>>    # @host-nodes: host nodes for its memory policy
>>>>    #
>>>>    # @policy: memory policy of memory backend
>>>> @@ -812,6 +815,7 @@
>>>>        'dump':       'bool',
>>>>        'prealloc':   'bool',
>>>>        'share':      'bool',
>>>> +    'reserve':    'bool',
>>>>        'host-nodes': ['uint16'],
>>>>        'policy':     'HostMemPolicy' }}
>>>
>>> Double-checking: true means definitely reserved, and false means
>>> definitely not reserved.  Correct?
>>
>> True means "reserved if applicable" which means "not reserved if not
>> applicable". False means "definitely not reserved".
>>
>> (any recommendation how to rephrase are appreciated; I tried my best --
>> this interface here makes it especially hard -- it's easier for the
>> property itself)
> 
> When is it "applicable"?
> 

When the OS supports it for the memory type and it hasn't been disabled.

Linux handling as described in
   [PATCH v6 09/15] util/mmap-alloc: Support RAM_NORESERVE via
   MAP_NORESERVE under Linux
and

   https://www.kernel.org/doc/Documentation/vm/overcommit-accounting

Summary *without* MAP_NORESERVE:

a) !Hugetlbfs with Memory overcommit disabled via
     ("/proc/sys/vm/overcommit_memory == 2"): never

b) !Hugetlbfs with Memory overcommit enabled
   1) Shared mappings on files: never

   2) Private mappings on files: only when writable (for us always)

   3) Shared anonymous memory: always

   4) Private anonymous memory: only when writable (for us always)

c) Hugetlbfs: Always


Under Windows: always. On other POSIX besides Linux -- don't know.

-- 
Thanks,

David / dhildenb



  reply	other threads:[~2021-04-23 11:34 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-21 12:26 [PATCH v6 00/15] RAM_NORESERVE, MAP_NORESERVE and hostmem "reserve" property David Hildenbrand
2021-04-21 12:26 ` [PATCH v6 01/15] util/mmap-alloc: Factor out calculation of the pagesize for the guard page David Hildenbrand
2021-04-21 12:26 ` [PATCH v6 02/15] util/mmap-alloc: Factor out reserving of a memory region to mmap_reserve() David Hildenbrand
2021-04-21 12:26 ` [PATCH v6 03/15] util/mmap-alloc: Factor out activating of memory to mmap_activate() David Hildenbrand
2021-04-21 12:26 ` [PATCH v6 04/15] softmmu/memory: Pass ram_flags to qemu_ram_alloc_from_fd() David Hildenbrand
2021-04-21 12:26 ` [PATCH v6 05/15] softmmu/memory: Pass ram_flags to memory_region_init_ram_shared_nomigrate() David Hildenbrand
2021-04-21 12:33   ` Philippe Mathieu-Daudé
2021-04-21 12:26 ` [PATCH v6 06/15] softmmu/memory: Pass ram_flags to qemu_ram_alloc() and qemu_ram_alloc_internal() David Hildenbrand
2021-04-21 12:34   ` Philippe Mathieu-Daudé
2021-04-21 12:26 ` [PATCH v6 07/15] util/mmap-alloc: Pass flags instead of separate bools to qemu_ram_mmap() David Hildenbrand
2021-04-21 12:37   ` Philippe Mathieu-Daudé
2021-04-21 12:26 ` [PATCH v6 08/15] memory: Introduce RAM_NORESERVE and wire it up in qemu_ram_mmap() David Hildenbrand
2021-04-21 12:26 ` [PATCH v6 09/15] util/mmap-alloc: Support RAM_NORESERVE via MAP_NORESERVE under Linux David Hildenbrand
2021-04-21 12:26 ` [PATCH v6 10/15] hostmem: Wire up RAM_NORESERVE via "reserve" property David Hildenbrand
2021-04-23 11:14   ` Markus Armbruster
2021-04-23 11:16     ` David Hildenbrand
2021-04-23 12:11       ` Markus Armbruster
2021-04-23 11:18     ` David Hildenbrand
2021-04-23 12:10       ` Markus Armbruster
2021-04-23 14:21         ` David Hildenbrand
2021-04-23 14:53           ` Markus Armbruster
2021-04-21 12:26 ` [PATCH v6 11/15] qmp: Clarify memory backend properties returned via query-memdev David Hildenbrand
2021-04-21 21:00   ` Eduardo Habkost
2021-04-23 10:55   ` Markus Armbruster
2021-04-21 12:26 ` [PATCH v6 12/15] qmp: Include "share" property of memory backends David Hildenbrand
2021-04-21 21:01   ` Eduardo Habkost
2021-04-23 11:15   ` Markus Armbruster
2021-04-21 12:26 ` [PATCH v6 13/15] hmp: Print "share" property of memory backends with "info memdev" David Hildenbrand
2021-04-21 21:04   ` Eduardo Habkost
2021-04-23 11:15   ` Markus Armbruster
2021-04-21 12:26 ` [PATCH v6 14/15] qmp: Include "reserve" property of memory backends David Hildenbrand
2021-04-21 21:05   ` Eduardo Habkost
2021-04-23 11:00   ` Markus Armbruster
2021-04-23 11:03     ` David Hildenbrand
2021-04-23 11:21       ` Markus Armbruster
2021-04-23 11:33         ` David Hildenbrand [this message]
2021-04-23 12:13           ` Markus Armbruster
2021-04-23 12:29             ` David Hildenbrand
2021-04-23 14:13               ` David Hildenbrand
2021-04-23 14:55                 ` Markus Armbruster
2021-04-23 15:04                   ` David Hildenbrand
2021-04-21 12:26 ` [PATCH v6 15/15] hmp: Print "reserve" property of memory backends with "info memdev" David Hildenbrand
2021-04-21 21:05   ` Eduardo Habkost
2021-04-23 11:16   ` Markus Armbruster
2021-04-21 21:06 ` [PATCH v6 00/15] RAM_NORESERVE, MAP_NORESERVE and hostmem "reserve" property Eduardo Habkost
2021-04-23 10:35   ` David Hildenbrand
2021-04-28 16:35     ` Eduardo Habkost

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=79cdbd39-cf5c-a8ab-b2c9-68d8e4ab2333@redhat.com \
    --to=david@redhat.com \
    --cc=armbru@redhat.com \
    --cc=dgilbert@redhat.com \
    --cc=ehabkost@redhat.com \
    --cc=groug@kaod.org \
    --cc=imammedo@redhat.com \
    --cc=mapfelba@redhat.com \
    --cc=mst@redhat.com \
    --cc=muriloo@linux.ibm.com \
    --cc=pbonzini@redhat.com \
    --cc=peterx@redhat.com \
    --cc=philmd@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=richard.henderson@linaro.org \
    --cc=stefanha@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.