qemu-devel.nongnu.org archive mirror
 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: Re: [Qemu-devel] [PATCH v4 0/3] numa: deprecate '-numa node, mem' and default memory distribution
Date: Mon, 17 Jun 2019 15:11:33 +0200	[thread overview]
Message-ID: <20190617151133.0af9fd43@redhat.com> (raw)
In-Reply-To: <1559205199-233510-1-git-send-email-imammedo@redhat.com>

On Thu, 30 May 2019 10:33:16 +0200
Igor Mammedov <imammedo@redhat.com> wrote:

> Changes since v3:
>   - simplify series by dropping idea of showing property values in "qom-list-properties"
>     and use MachineInfo in QAPI schema instead
> 
> Changes since v2:
>   - taking in account previous review, implement a way for mgmt to intospect if
>     '-numa node,mem' is supported by machine type as suggested by Daniel at
>              https://www.mail-archive.com/qemu-devel@nongnu.org/msg601220.html
>       * ammend "qom-list-properties" to show property values
>       * add "numa-mem-supported" machine property to reflect if '-numa node,mem=SZ'
>         is supported. It culd be used with '-machine none' or at runtime with
>         --preconfig before numa memory mapping are configured
>   * minor fixes to deprecation documentation mentioning "numa-mem-supported" property
> 
>  1) "I'm considering to deprecating -mem-path/prealloc CLI options and replacing
> them with a single memdev Machine property to allow interested users to pick
> used backend for initial RAM (fixes mixed -mem-path+hostmem backends issues)
> and as a transition step to modeling initial RAM as a Device instead of
> (ab)using MemoryRegion APIs."
> (for more details see: https://www.mail-archive.com/qemu-devel@nongnu.org/msg596314.html)
> 
> However there is a couple of roadblocks on the way (s390x and numa memory handling).
> I think I finally thought out a way to hack s390x in migration compatible manner,
> but I don't see any way to do it for -numa node,mem and default RAM assignement
> to nodes. Considering both numa usecases aren't meaningfully using NUMA (aside
> guest side testing) and could be replaced with explicitly used memdev parameter,
> I'd like to propose removing these fake NUMA friends on new machine types,
> hence this deprecation. And once the last machie type that supported the option
> is removed we would be able to remove option altogether.
> 
> As result of removing deprecated options and replacing initial RAM allocation
> with 'memdev's (1), QEMU will allocate guest RAM in consistent way, fixing mixed
> use-case and allowing boards to move towards modelling initial RAM as Device(s).
> Which in its own turn should allow to cleanup NUMA/HMP/memory accounting code
> more by dropping ad-hoc node_mem tracking and reusing memory device enumeration
> instead.

Eduardo,

could you take and merge it via numa/machine tree?

> 
> Reference to previous versions:
>  * https://www.mail-archive.com/qemu-devel@nongnu.org/msg617694.html
> 
> CC: libvir-list@redhat.com
> CC: ehabkost@redhat.com
> CC: pbonzini@redhat.com
> CC: berrange@redhat.com
> CC: armbru@redhat.com
> 
> Igor Mammedov (3):
>   machine: show if CLI option '-numa node,mem' is supported in QAPI
>     schema
>   numa: deprecate 'mem' parameter of '-numa node' option
>   numa: deprecate implict memory distribution between nodes
> 
>  include/hw/boards.h  |  3 +++
>  hw/arm/virt.c        |  1 +
>  hw/i386/pc.c         |  1 +
>  hw/ppc/spapr.c       |  1 +
>  numa.c               |  5 +++++
>  qapi/misc.json       |  5 ++++-
>  qemu-deprecated.texi | 24 ++++++++++++++++++++++++
>  vl.c                 |  1 +
>  8 files changed, 40 insertions(+), 1 deletion(-)
> 



      parent reply	other threads:[~2019-06-17 13:12 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-30  8:33 [Qemu-devel] [PATCH v4 0/3] numa: deprecate '-numa node, mem' and default memory distribution Igor Mammedov
2019-05-30  8:33 ` [Qemu-devel] [PATCH v4 1/3] machine: show if CLI option '-numa node, mem' is supported in QAPI schema Igor Mammedov
2019-06-07 17:39   ` Markus Armbruster
2019-06-07 18:02     ` Eduardo Habkost
2019-06-11  8:29       ` Markus Armbruster
2019-06-10 12:31     ` Igor Mammedov
2019-06-10 13:10   ` [Qemu-devel] [PATCH v5 " Igor Mammedov
2019-06-11  8:30     ` Markus Armbruster
2019-05-30  8:33 ` [Qemu-devel] [PATCH v4 2/3] numa: deprecate 'mem' parameter of '-numa node' option Igor Mammedov
2019-05-30  8:33 ` [Qemu-devel] [PATCH v4 3/3] numa: deprecate implict memory distribution between nodes Igor Mammedov
2019-06-05 17:33 ` [Qemu-devel] [PATCH v4 0/3] numa: deprecate '-numa node, mem' and default memory distribution Daniel P. Berrangé
2019-06-05 18:06   ` Eduardo Habkost
2019-06-06  9:16     ` Daniel P. Berrangé
2019-06-07 17:28 ` Markus Armbruster
2019-06-10 12:19   ` Igor Mammedov
2019-06-17 13:11 ` 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=20190617151133.0af9fd43@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).