All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
To: David Hildenbrand <david@redhat.com>
Cc: Igor Mammedov <imammedo@redhat.com>,
	Vadim Galitsyn <vadim.galitsyn@profitbricks.com>,
	Eugene Crosser <evgenii.cherkashin@profitbricks.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 15:43:47 +0100	[thread overview]
Message-ID: <20180622144346.GC2415@work-vm> (raw)
In-Reply-To: <cbb7f70c-20ff-324b-e286-ec881db00925@redhat.com>

* David Hildenbrand (david@redhat.com) wrote:
> On 22.06.2018 16:11, Igor Mammedov wrote:
> > 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).
> 
> I agree, it is "coldplugged" and should therefore be considered as
> "plugged". I'll prepare a patch, then we can discuss.
> 
> > 
> >> - 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.
> 
> I agree that it depends. So I wonder if virtio-balloon should be fixed
> too, to consider nvdimms. (the complete balloon interface is broken, one
> does not specify how much memory to inflate/deflate, but how much memory
> the guest should have. One of the reasons why I dislike global balloon
> drivers. They don't play nicely along with memory devices (that are e.g.
> got hotplugged, or nvdimm). But that is a different story :) ).

Balloon and NVDimm feels a bit different; if you're actually holding
persistent data on the nvdimm you don't want to blow away pages when you
want some more RAM to play with on the host.

Dave

> >  
> >> 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.
> 
> We have such an interface for memory devices (info memory-devices), but
> not for initial memory. That is at least now accessible via "info
> memory_size_summary".
> 
> > 
> > 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.
> 
> I agree.
> 
> -- 
> 
> Thanks,
> 
> David / dhildenb
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK

  reply	other threads:[~2018-06-22 14:43 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
2018-06-22 14:19   ` David Hildenbrand
2018-06-22 14:43     ` Dr. David Alan Gilbert [this message]
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=20180622144346.GC2415@work-vm \
    --to=dgilbert@redhat.com \
    --cc=armbru@redhat.com \
    --cc=david@redhat.com \
    --cc=eblake@redhat.com \
    --cc=evgenii.cherkashin@profitbricks.com \
    --cc=imammedo@redhat.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.