WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

To: "Tim Deegan" <Tim.Deegan@xxxxxxxxxx>
Subject: Re: [Xen-devel] pre-reservation of memory for domain creation
From: "Jan Beulich" <JBeulich@xxxxxxxxxx>
Date: Tue, 09 Feb 2010 11:21:27 +0000
Cc: Dongxiao Xu <dongxiao.xu@xxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Keir Fraser <Keir.Fraser@xxxxxxxxxxxxx>
Delivery-date: Tue, 09 Feb 2010 03:21:48 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20100209103958.GC368@xxxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <4B4CA40C0200007800029657@xxxxxxxxxxxxxxxxxx> <C7724B76.6265%keir.fraser@xxxxxxxxxxxxx> <4B4CAEB9020000780002969A@xxxxxxxxxxxxxxxxxx> <6CADD16F56BC954D8E28F3836FA7ED7112A79326F2@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <4B4D8A9402000078000299C3@xxxxxxxxxxxxxxxxxx> <6CADD16F56BC954D8E28F3836FA7ED7112A7932EBF@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <4B4EEB300200007800029E45@xxxxxxxxxxxxxxxxxx> <20100114124619.GE30054@xxxxxxxxxxxxxxxxxxxxxxx> <4B70490D020000780002E4AD@xxxxxxxxxxxxxxxxxx> <20100209103958.GC368@xxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
>>> 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