|   | 
      | 
  
  
      | 
      | 
  
 
     | 
    | 
  
  
     | 
    | 
  
  
    |   | 
      | 
  
  
    | 
         
xen-devel
[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
 |   
 
| <Prev in Thread] | 
Current Thread | 
[Next in Thread>
 |  
- [Xen-devel] Memory overhead of HVM domains,
Charles Coffing <=
 
 
 |  
  
 | 
    | 
  
  
    |   | 
    |