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

["Jan Beulich" <JBeulich@xxxxxxxxxx>]

>>> Tim Deegan <Tim.Deegan@xxxxxxxxxx> 14.01.10 13:46 >>>
>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.

So is there a way to quantify that? In particular, is that *initial*
amount in any way dependent on the number of vCPU-s?

>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 full memory assignment happens after vCPU-s got assigned, but
the initial assignment happens before. Dongxiao's patch tried to account
for that, but neither was that patch accepted so far, nor am I
convinced this is really correct or even necessary.

I'm re-raising this question because we're not seeming to make any
progress towards a satisfactory resolution of the regression c/s 20389
introduced.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel