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

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



>>> Tim Deegan <Tim.Deegan@xxxxxxxxxx> 09.02.10 11:39 >>>
>At 16:25 +0000 on 08 Feb (1265646333), Jan Beulich wrote:
>> >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?
>
>Sort of, and not very.  We currently allocate about a page per megabyte
>for p2m; we use a small amount per vcpu (maybe as many as 7 pages)
>before the vpcu can be scheduled.

Sounds all pretty vague to base calculations upon.

Also, a per-megabyte allocation seems questionable at this point,
since with that even the code prior to 20389 would have failed (with
1M pre-allocated you wouldn't have been able to create a 1G guest).
Besides that I don't think Xen even knows the memory size of the
guest prior to the full ballooning having taken place in Dom0.

>> 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.
>
>I thought the regression was the Xen crash and that should be fixed by 
>the patch I sent.

The Xen crash was what Keir talked about; I was referring to the
increased early allocation which continues to be out of sync with the
ballooning happening in the tools (and hence in environments where
ballooning is being used likely has no chance of succeeding).

Jan


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