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

[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


 


Rackspace

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