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

["Charles Coffing" <ccoffing@xxxxxxxxxx>]

On Tue, Apr 11, 2006 at  3:58 PM, in message
<FFEFE1749526634699CD3AC2EDB7627A0184B6E7@pdsmsx406>, "Jiang, Yunhong"
<yunhong.jiang@xxxxxxxxx> wrote: 
> From you definition of overhead, I think your overhead should include
the 
> shadow page table, p2m table and those shadow cache, am I right?

Right.  But 10 to 14 MB** for just a 16 MB domU seems excessive for
these things, doesn't it?

** my numbers below minus 4 MB for video


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

That might help explain it, thanks.


> 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