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: Jan Beulich <JBeulich@xxxxxxxxxx>, Keir Fraser <keir.fraser@xxxxxxxxxxxxx>, Tim Deegan <Tim.Deegan@xxxxxxxxxxxxx>
Subject: RE: [Xen-devel] pre-reservation of memory for domain creation
From: "Xu, Dongxiao" <dongxiao.xu@xxxxxxxxx>
Date: Fri, 22 Jan 2010 17:20:36 +0800
Accept-language: en-US
Acceptlanguage: en-US
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Fri, 22 Jan 2010 01:21:01 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4B596C57020000780002B7F2@xxxxxxxxxxxxxxxxxx>
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> <4B588DC4020000780002B5E2@xxxxxxxxxxxxxxxxxx> <6CADD16F56BC954D8E28F3836FA7ED711318B68794@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <4B596C57020000780002B7F2@xxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcqbOt0VP1G6MNAAS6SzSsfIZBqXSwABCYdg
Thread-topic: [Xen-devel] pre-reservation of memory for domain creation
Jan, 

Removing this 1M pre-allocation of shadow memory may have difficulty.
If we want to ensure safety, we should balloon out enough memory before
any shadow operation. This needs to move the full balloon of memory in
the beginning place of _constructDomain(), and this needs the domain
vcpu number information. This change may have a flaw that we easily
ballon out so much memory at an early stage and guest maybe could
not correctly boot up (for example, error configuration).

Another problem is that, currently the operations of setting vcpu number
and alloc_vcpu() are done within one hypercall. Memory ballooning and
allocation should be called between them in order to allocate 128 pages
for each vcpu (Actually I think this "128" is also from experience).

Thanks!
Dongxiao



Jan Beulich wrote:
>>>> "Xu, Dongxiao" <dongxiao.xu@xxxxxxxxx> 22.01.10 05:28 >>>
>> Hi, Jan,
>>    This patch may not work because when allocating 128 pages for
>> each vcpu, tool side hasn't balloon so much memory for it. So the
>>    allocation may fail. What about this solution, we change the tool
>> side to balloon more memory for pre-reserve memory (For example
>> 8M),and pre-alloc 4M for domain creation (which works for 128 vcpus)?
> 
> Based on what information do you judge that 4M will work for 128
> vCPU-s?
> 
> And how did you conclude that ballooning 8M will be sufficient to be
> able to allocate 4M (before the patch in question 4M got ballooned in
> order to be able to allocate 1M)?
> 
>> Anyway like the comment in _constructDomain, it's still somewhat
>> hacky.
> 
> Indeed. Which is why I'm concerned about extending this hack.
> 
> Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel