From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:38287) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fWMnC-0005wO-JY for qemu-devel@nongnu.org; Fri, 22 Jun 2018 10:12:03 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fWMnB-00061a-I9 for qemu-devel@nongnu.org; Fri, 22 Jun 2018 10:12:02 -0400 Received: from mx3-rdu2.redhat.com ([66.187.233.73]:50634 helo=mx1.redhat.com) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1fWMnB-00061D-CT for qemu-devel@nongnu.org; Fri, 22 Jun 2018 10:12:01 -0400 Date: Fri, 22 Jun 2018 16:11:58 +0200 From: Igor Mammedov Message-ID: <20180622161158.3a88c371@redhat.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [Question] inconsistent memory amount statistics List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: David Hildenbrand Cc: Vadim Galitsyn , Eugene Crosser , "Dr. David Alan Gilbert" , Markus Armbruster , Eric Blake , "qemu-devel@nongnu.org" On Fri, 22 Jun 2018 09:41:15 +0200 David Hildenbrand 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.