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

Re: [Xen-devel] pre-reservation of memory for domain creation



At 09:00 +0000 on 14 Jan (1263459616), Jan Beulich wrote:
> >>> "Xu, Dongxiao" <dongxiao.xu@xxxxxxxxx> 14.01.10 08:19 >>>
> >    Currently guest initialization process in xend (XendDomainInfo.py) is: 
> >
> >    _constructDomain() --> domain_create() --> domain_max_vcpus() ... -->
> >    _initDomain() --> shadow_mem_control() ...
> 
> While the patch certainly matches what I had in mind, with this sequence
> it is clear that the tools still will need adjustment: The full ballooning 
> only
> happens from _initDomain(), and hence the pre-reservation (from
> _constructDomain) of 4Mb would still be too small for large vCPU counts.
> 
> I wonder though what all this memory is needed for before the domain
> (not to speak of secondary CPUs) actually gets started. If that could be
> got under control, tools side adjustment would not be necessary. Tim?

Hmmm.  Some shadow memory has to be allocated before the VCPUs are
initialized so that they can be given monitor pagetables etc.  Some
shadow memory has to be allocated before the guest's main memory is
assigned because the p2m is built out of shadow memory.

It looks like there are (at least) two bugs here:
 - shadow_min_acceptable_pages() returns 0 for a domain with 
   no vcpus, leading to a domain having shadow enabled but no 
   shadow memory at all.
 - shadow_min_acceptable_pages() increases as more VCPUs are assigned
   but the shadow allocation is never increased to match. 

Fixing the first one should be enough, so long as xend assignd vcpus and
memory before assigning shadow memory properly (which I believe it
does).  Patch attached.

The separate issue of how much memory should be ballooned out before
starting a domain really needs a full overhaul of all allocations in Xen
so that we can assign blame for every page. :)  Shadow memory is the
best-behaved part of all this; most HVM overhead is just allocated
anonymously. 

Cheers,

Tim.

-- 
Tim Deegan <Tim.Deegan@xxxxxxxxxx>
Principal Software Engineer, Citrix Systems (R&D) Ltd.
[Company #02300071, SL9 0DZ, UK.]

Attachment: shmem
Description: Text document

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