[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |