|
|
|
|
|
|
|
|
|
|
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 <=
|
|
|
|
|