[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Xen-devel] Memory overhead of HVM domains


  • To: "Charles Coffing" <ccoffing@xxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • From: "Jiang, Yunhong" <yunhong.jiang@xxxxxxxxx>
  • Date: Wed, 12 Apr 2006 05:58:52 +0800
  • Delivery-date: Tue, 11 Apr 2006 14:59:25 -0700
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AcZdoCOgEmaD4rkzRuyRgvH+B3k2dwAD4fHg
  • Thread-topic: [Xen-devel] Memory overhead of HVM domains

>From you definition of overhead, I think your overhead should include the 
>shadow page table, p2m table and those shadow cache, am I right?

Not sure if any other sources.

Also I just find a bug on qemu, which may occupy double size of the video 
memory if you are using Xwindow. 

Thanks
Yunhong Jiang

---Original Message-----
>From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
>[mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Charles Coffing
>Sent: 2006年4月11日 12:43
>To: xen-devel@xxxxxxxxxxxxxxxxxxx
>Subject: [Xen-devel] Memory overhead of HVM domains
>
>Hi,
>
>I was trying to find a solution for bug #521 ("video ram for hvm guests not
>properly accounted for when ballooning").  The trivial (although ugly) answer
>is to allocate an extra (hard-coded) 1026 pages in the getDomainMemory()
>function to account for the increase_reservation that qemu-dm will do.
>
>However, ugly or not, this doesn't work.  In reality, an HVM domain requires
>some extra memory in addition to its nominal memory size.  Here are some
>measurements I did (everything in MB; overhead is approximate and measured by
>looking at memory remaining in Xen's DMA and DOM memory zones before and after
>creating the HVM domU):
>
>Nominal    Overhead
>-------    --------
>   16        14.2
>  128        16.3
>  256        16.6
>  512        17.1
> 1024        18.4
>
>4 MB of this is due to the VM's video memory.  I expect additional state would
>be stored in the qemu-dm process, but that would consume already-allocated dom0
>memory, and so wouldn't be represented above.  I also see references to VMCBs
>/ VMCSs, but those are getting allocated on Xen's heap, and so also not
>represented above.
>
>So several questions:
>
>1. Where's the extra memory going?
>
>2. Should we even try to calculate it for auto-ballooning?  It seems like many
>factors could affect it, and any such calculation would be very brittle.
>
>I'll gladly code up and test a patch to auto-balloon for HVM domains, but I 
>first
>want to understand what's going on.
>
>Thanks,
>Chuck
>
>
>
>_______________________________________________
>Xen-devel mailing list
>Xen-devel@xxxxxxxxxxxxxxxxxxx
>http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.