All of lore.kernel.org
 help / color / mirror / Atom feed
From: Igor Mammedov <imammedo@redhat.com>
To: qemu-devel@nongnu.org
Cc: libvir-list@redhat.com, pbonzini@redhat.com, berrange@redhat.com,
	ehabkost@redhat.com, armbru@redhat.com
Subject: [Qemu-devel] [PATCH v3 6/6] numa: deprecate implict memory distribution between nodes
Date: Fri, 17 May 2019 09:45:19 +0200	[thread overview]
Message-ID: <1558079119-320634-7-git-send-email-imammedo@redhat.com> (raw)
In-Reply-To: <1558079119-320634-1-git-send-email-imammedo@redhat.com>

Implicit RAM distribution between nodes has exactly the same issues as:
  "numa: deprecate 'mem' parameter of '-numa node' option"
only with QEMU being the user that's 'adding' 'mem' parameter.

Deprecate it, to get it out of the way so that we could consolidate
guest RAM allocation using memory backends making it consistent and
possibly later on transition to using memory devices instead of
adhoc memory mapping of initial RAM.
---
 v3:
   - update deprecation doc, s/4.0/4.1/
   - mention that legacy 'mem' option could also be used to
     provide explicit memory distribution for old machine types

Signed-off-by: Igor Mammedov <imammedo@redhat.com>
---
 numa.c               | 3 +++
 qemu-deprecated.texi | 8 ++++++++
 2 files changed, 11 insertions(+)

diff --git a/numa.c b/numa.c
index 2205773..6d45a1f 100644
--- a/numa.c
+++ b/numa.c
@@ -409,6 +409,9 @@ void numa_complete_configuration(MachineState *ms)
         if (i == nb_numa_nodes) {
             assert(mc->numa_auto_assign_ram);
             mc->numa_auto_assign_ram(mc, numa_info, nb_numa_nodes, ram_size);
+            warn_report("Default splitting of RAM between nodes is deprecated,"
+                        " Use '-numa node,memdev' to explictly define RAM"
+                        " allocation per node");
         }
 
         numa_total = 0;
diff --git a/qemu-deprecated.texi b/qemu-deprecated.texi
index 995a96c..546f722 100644
--- a/qemu-deprecated.texi
+++ b/qemu-deprecated.texi
@@ -88,6 +88,14 @@ In future new machine versions will not accept the option but it will keep
 working with old machine types. User can inspect read-only machine property
 'numa-mem-supported' to check if specific machine type (not) supports the option.
 
+@subsection -numa node (without memory specified) (since 4.1)
+
+Splitting RAM by default between NUMA nodes has the same issues as @option{mem}
+parameter described above with the difference that the role of the user plays
+QEMU using implicit generic or board specific splitting rule.
+Use @option{memdev} with @var{memory-backend-ram} backend or @option{mem} (if
+it's supported by used machine type) to define mapping explictly instead.
+
 @section QEMU Machine Protocol (QMP) commands
 
 @subsection block-dirty-bitmap-add "autoload" parameter (since 2.12.0)
-- 
2.7.4



      parent reply	other threads:[~2019-05-17  7:51 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-17  7:45 [Qemu-devel] [PATCH v3 0/6] numa: deprecate '-numa node, mem' and default memory distribution Igor Mammedov
2019-05-17  7:45 ` [Qemu-devel] [PATCH v3 1/6] pc: fix possible NULL pointer dereference in pc_machine_get_device_memory_region_size() Igor Mammedov
2019-05-27 16:36   ` Markus Armbruster
2019-05-28 13:46     ` Igor Mammedov
2019-05-17  7:45 ` [Qemu-devel] [PATCH v3 2/6] qmp: make "qom-list-properties" show initial property values Igor Mammedov
2019-05-27 18:15   ` Markus Armbruster
2019-05-17  7:45 ` [Qemu-devel] [PATCH v3 3/6] qmp: qmp_qom_list_properties(): ignore empty string options Igor Mammedov
2019-05-27 18:22   ` Markus Armbruster
2019-05-17  7:45 ` [Qemu-devel] [PATCH v3 4/6] numa: introduce "numa-mem-supported" machine property Igor Mammedov
2019-05-27 18:38   ` Markus Armbruster
2019-05-28 13:14     ` Igor Mammedov
2019-05-27 18:52   ` Eduardo Habkost
2019-05-17  7:45 ` [Qemu-devel] [PATCH v3 5/6] numa: deprecate 'mem' parameter of '-numa node' option Igor Mammedov
2019-05-17  7:45 ` Igor Mammedov [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=1558079119-320634-7-git-send-email-imammedo@redhat.com \
    --to=imammedo@redhat.com \
    --cc=armbru@redhat.com \
    --cc=berrange@redhat.com \
    --cc=ehabkost@redhat.com \
    --cc=libvir-list@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /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.