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

xen-devel

[Top] [All Lists]

[Xen-devel] Re: non-zero order allocations in shadow code may prevent li

To: "Tim Deegan" <Tim.Deegan@xxxxxxxxxxxxx>
Subject: [Xen-devel] Re: non-zero order allocations in shadow code may prevent live migration
From: "Jan Beulich" <jbeulich@xxxxxxxxxx>
Date: 2007年9月27日 12:28:10 +0100
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: 2007年9月27日 04:27:56 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <20070927105024.GB23760@xxxxxxxxxxxxxxxxxxxxx>
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/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <46FB995B.76E4.0078.0@xxxxxxxxxx> <20070927105024.GB23760@xxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
>>> Tim Deegan <Tim.Deegan@xxxxxxxxxxxxx> 27.09.07 12:50 >>>
>At 10:51 +0100 on 27 Sep (1190890315), Jan Beulich wrote:
>> So the bottom line is - sh_set_allocation() really shouldn't need to allocate
>> non-zero order pages except for hvm domains.
>
>Actually, if you're having fragmentation issues, won't that stop you
>from booting HVM domains as well?
I'm sure we would, but in the given case the customer just cares about PV.
However, HVM would likely see the issue much less frequently if (as I assume,
but didn't verify) shadow mode gets enabled before normal domain memory
gets allocated, because that would generally allow a much wider pool for
picking out the needed higher order pages. Nevertheless I would think that
even for HVM domains the shadow shouldn't need to make its entire
allocation in order 2 chunks, but could limit this to just the amount it really
knows it'll need (1 per vCPU as I understand it), then continue with order 1
chunks (not sure about their count, but for forward progress I think you'll
need at most 6 {,f}l1_32_shadow pages per vCPU).
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
<Prev in Thread] Current Thread [Next in Thread>
Previous by Date: [Xen-devel] Re: non-zero order allocations in shadow code may prevent live migration , Jan Beulich
Next by Date: [Xen-devel] [PATCH][TOOLS] ioemu: Build fixes for BSD and bug fixes from BSD , Christoph Egger
Previous by Thread: [Xen-devel] Re: non-zero order allocations in shadow code may prevent live migration , Tim Deegan
Next by Thread: [Xen-devel] Re: non-zero order allocations in shadow code may prevent live migration , Tim Deegan
Indexes: [Date] [Thread] [Top] [All Lists]

Copyright ©, Citrix Systems Inc. All rights reserved. Legal and Privacy
Citrix This site is hosted by Citrix

AltStyle によって変換されたページ (->オリジナル) /