All of lore.kernel.org
 help / color / mirror / Atom feed
From: Igor Mammedov <imammedo@redhat.com>
To: David Hildenbrand <david@redhat.com>
Cc: Vadim Galitsyn <vadim.galitsyn@profitbricks.com>,
	Eugene Crosser <evgenii.cherkashin@profitbricks.com>,
	"Dr. David Alan Gilbert" <dgilbert@redhat.com>,
	Markus Armbruster <armbru@redhat.com>,
	Eric Blake <eblake@redhat.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] [Question] inconsistent memory amount statistics
Date: Fri, 22 Jun 2018 16:11:58 +0200	[thread overview]
Message-ID: <20180622161158.3a88c371@redhat.com> (raw)
In-Reply-To: <c7c8dfc5-d7b3-a22e-586c-4436214c7b9f@redhat.com>

On Fri, 22 Jun 2018 09:41:15 +0200
David Hildenbrand <david@redhat.com> wrote:

> Starting qemu with and querying some outputs:
> 
> [...]
> -m 4G,maxmem=20G,slots=2 \
> -numa node,nodeid=0,cpus=0-1 -numa node,nodeid=1,cpus=2-3 \
> [...]
> -device virtio-balloon \
> -object memory-backend-ram,id=mem0,size=8G \
> -device pc-dimm,id=dimm0,memdev=mem0 \
> -object memory-backend-ram,id=mem1,size=8G \
> -device nvdimm,id=dimm1,memdev=mem1,node=1
> 
> (qemu) info numa
> info numa
> 2 nodes
> node 0 cpus: 0 1
> node 0 size: 10240 MB
> node 0 plugged: 0 MB
> node 1 cpus: 2 3
> node 1 size: 10240 MB
> node 1 plugged: 0 MB
> 
> 
> (qemu) info memory_size_summary
> info memory_size_summary
> base memory: 4294967296
> plugged memory: 17179869184
> 
> (qemu) info memory-devices
> info memory-devices
> Memory device [dimm]: "dimm0"
>   addr: 0x140000000
>   slot: 0
>   node: 0
>   size: 8589934592
>   memdev: /objects/mem0
>   hotplugged: false
>   hotpluggable: true
> Memory device [nvdimm]: "dimm1"
>   addr: 0x340000000
>   slot: 1
>   node: 1
>   size: 8589934592
>   memdev: /objects/mem1
>   hotplugged: false
>   hotpluggable: true
> 
> 
> (qemu) info balloon
> info balloon
> balloon: actual=12288
> 
> 
> 1. "info numa"
> - considers both, pc-dimm and nvdimm
> - "-device ..." are considered as "!plugged" although it could be
>   theoretically "unplugged"
I'd think that this part is broken there should be no difference
-device vs device_add here (the only difference here is cold/hot-plugged).

> - device_add devices are considered as "plugged"
 
> 
> 2. "info memory_size_summary"
> - considers both, pc-dimm and nvdimm
> - "-device ..." are considered as "plugged"
> - device_add devices are considered as "plugged"
> 
> 3. "info balloon"
> - does not consider nvdimm devices to calculate "actual"
> -- actual = get_current_ram_size() - inflated
> -- get_current_ram_size() does not consider nvdimm
> 
> So we have some inconsistency in regards of
> 1. What is considered memory and what not (pc-dimm vs nvdimm)
> 2. What is considered plugged memory (-device vs. device_add)
> 
> 
> Is this what we expect? I think we should make up our mind
> 
> a) what "plugged" means
> b) which stats should consider "nvdimm" and which not.
> 
> I would have guessed that "nvdimms" might be memory devices but should
> never count towards memory statistics ("not actually ram" - they might
> be OK).
well, it depends. 
nvdimm might be actually battery powered RAM with nvram backend.
 
> Especially "info memory_size_summary" ... "plugged-memory - amount of
> memory that was hot-plugged" - this seems to be wrong. And I wonder if
> we should exclude nvdimm from that.
These summary interfaces look broken to me as what is memory might be
unclear. It would be better if we just provide primitives to query/list
individual and let user do the math the way he/she prefers.

Wrt QEMU's CLI interface /VM it emulates/ it's all RAM,
so if we report some statistics we probably should include nvdimm as well.

  reply	other threads:[~2018-06-22 14:12 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-22  7:41 [Qemu-devel] [Question] inconsistent memory amount statistics David Hildenbrand
2018-06-22 14:11 ` Igor Mammedov [this message]
2018-06-22 14:19   ` David Hildenbrand
2018-06-22 14:43     ` Dr. David Alan Gilbert
2018-06-22 14:54       ` David Hildenbrand

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=20180622161158.3a88c371@redhat.com \
    --to=imammedo@redhat.com \
    --cc=armbru@redhat.com \
    --cc=david@redhat.com \
    --cc=dgilbert@redhat.com \
    --cc=eblake@redhat.com \
    --cc=evgenii.cherkashin@profitbricks.com \
    --cc=qemu-devel@nongnu.org \
    --cc=vadim.galitsyn@profitbricks.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.