qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Eric Blake <eblake@redhat.com>
To: Igor Mammedov <imammedo@redhat.com>, qemu-devel@nongnu.org
Cc: peter.maydell@linaro.org, ehabkost@redhat.com, mst@redhat.com,
	libvir-list@redhat.com, Michal Privoznik <mprivozn@redhat.com>,
	groug@kaod.org, qemu-arm@nongnu.org, qemu-ppc@nongnu.org,
	pbonzini@redhat.com, david@gibson.dropbear.id.au,
	rth@twiddle.net
Subject: Re: [PATCH v4] numa: forbid '-numa node,mem' for 5.1 and newer machine types
Date: Mon, 8 Jun 2020 10:53:27 -0500	[thread overview]
Message-ID: <06e37d7b-db66-e39c-22f1-5eff7370927b@redhat.com> (raw)
In-Reply-To: <20200608120344.728549-1-imammedo@redhat.com>

On 6/8/20 7:03 AM, Igor Mammedov wrote:
> Deprecation period is run out and it's a time to flip the switch
> introduced by cd5ff8333a.  Disable legacy option for new machine
> types (since 5.1) and amend documentation.
> 
> '-numa node,memdev' shall be used instead of disabled option
> with new machine types.
> 
> Signed-off-by: Igor Mammedov <imammedo@redhat.com>
> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
> ---

> +++ b/docs/system/deprecated.rst
> @@ -101,23 +101,6 @@ error in the future.
>   The ``-realtime mlock=on|off`` argument has been replaced by the
>   ``-overcommit mem-lock=on|off`` argument.
>   
> -``-numa node,mem=``\ *size* (since 4.1)
> -'''''''''''''''''''''''''''''''''''''''
> -
> -The parameter ``mem`` of ``-numa node`` is used to assign a part of

Present tense in the old text made sense because the old way still worked...

> -guest RAM to a NUMA node. But when using it, it's impossible to manage specified
> -RAM chunk on the host side (like bind it to a host node, setting bind policy, ...),
> -so guest end-ups with the fake NUMA configuration with suboptiomal performance.
> -However since 2014 there is an alternative way to assign RAM to a NUMA node
> -using parameter ``memdev``, which does the same as ``mem`` and adds
> -means to actualy manage node RAM on the host side. Use parameter ``memdev``
> -with *memory-backend-ram* backend as an replacement for parameter ``mem``
> -to achieve the same fake NUMA effect or a properly configured
> -*memory-backend-file* backend to actually benefit from NUMA configuration.
> -In future new machine versions will not accept the option but it will still
> -work with old machine types. User can check QAPI schema to see if the legacy
> -option is supported by looking at MachineInfo::numa-mem-supported property.
> -
>   ``-numa`` node (without memory specified) (since 4.1)
>   '''''''''''''''''''''''''''''''''''''''''''''''''''''
>   
> @@ -516,3 +499,23 @@ long starting at 1MiB, the old command::
>   can be rewritten as::
>   
>     qemu-nbd -t --image-opts driver=raw,offset=1M,size=100M,file.driver=qcow2,file.file.driver=file,file.file.filename=file.qcow2
> +
> +Command line options
> +--------------------
> +
> +``-numa node,mem=``\ *size* (removed in 5.1)
> +''''''''''''''''''''''''''''''''''''''''''''
> +
> +The parameter ``mem`` of ``-numa node`` is used to assign a part of

...but in the new text, if we completely got rid of 'mem', then past 
tense is preferred to describe what used to work.  s/is/was/

Other pre-existing typo and grammar problems worth fixing now:

> +guest RAM to a NUMA node. But when using it, it's impossible to manage specified

s/manage/manage a/

> +RAM chunk on the host side (like bind it to a host node, setting bind policy, ...),
> +so guest end-ups with the fake NUMA configuration with suboptiomal performance.

s/so guest end-ups/so the guest ends up/

> +However since 2014 there is an alternative way to assign RAM to a NUMA node
> +using parameter ``memdev``, which does the same as ``mem`` and adds
> +means to actualy manage node RAM on the host side. Use parameter ``memdev``

s/actualy/actually/

> +with *memory-backend-ram* backend as an replacement for parameter ``mem``

s/an/a/

> +to achieve the same fake NUMA effect or a properly configured
> +*memory-backend-file* backend to actually benefit from NUMA configuration.
> +In future new machine versions will not accept the option but it will still

If this sentence is still true:
s/In future new/New/

If the sentence is false (that is, we completely dropped 'mem' even for 
old machine versions), drop it.

> +work with old machine types. User can check QAPI schema to see if the legacy

s/check/check the/

> +option is supported by looking at MachineInfo::numa-mem-supported property.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3226
Virtualization:  qemu.org | libvirt.org



  parent reply	other threads:[~2020-06-08 15:54 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-08 12:03 [PATCH v4] numa: forbid '-numa node, mem' for 5.1 and newer machine types Igor Mammedov
2020-06-08 12:55 ` [PATCH v4] numa: forbid '-numa node,mem' " Michael S. Tsirkin
2020-06-08 15:12   ` Igor Mammedov
2020-06-08 15:27 ` Greg Kurz
2020-06-08 15:53 ` Eric Blake [this message]
2020-06-23  9:35 ` Paolo Bonzini

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=06e37d7b-db66-e39c-22f1-5eff7370927b@redhat.com \
    --to=eblake@redhat.com \
    --cc=david@gibson.dropbear.id.au \
    --cc=ehabkost@redhat.com \
    --cc=groug@kaod.org \
    --cc=imammedo@redhat.com \
    --cc=libvir-list@redhat.com \
    --cc=mprivozn@redhat.com \
    --cc=mst@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-arm@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-ppc@nongnu.org \
    --cc=rth@twiddle.net \
    /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).