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

[Xen-devel] Overcommitting memory (was: Disable auto-balloon on ia64)

To: "Keir Fraser" <Keir.Fraser@xxxxxxxxxxxx>, "Kevin Tian" <kevin.tian@xxxxxxxxx>
Subject: [Xen-devel] Overcommitting memory (was: Disable auto-balloon on ia64)
From: "Charles Coffing" <ccoffing@xxxxxxxxxx>
Date: Mon, 22 May 2006 09:12:27 -0600
Cc: xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, Alex Williamson <alex.williamson@xxxxxx>, xen-ia64-devel <xen-ia64-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Mon, 22 May 2006 08:13:04 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <de6a6f8a49c55295ad1cedb0718099ef@xxxxxxxxxxxx>
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: <571ACEFD467F7749BC50E0A98C17CDD8094E7C7F@pdsmsx403> <de6a6f8a49c55295ad1cedb0718099ef@xxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
>>> On Mon, May 22, 2006 at  3:37 AM, in message
<de6a6f8a49c55295ad1cedb0718099ef@xxxxxxxxxxxx>, Keir Fraser
<Keir.Fraser@xxxxxxxxxxxx> wrote: 

> On 22 May 2006, at 10:06, Tian, Kevin wrote:
> 
>>      We just need to reverse the whole change for ia64, since both
domU 
>> and domVTI are insert a hole by this auto- balloon patch. Due to 
>> missing balloon support on xen/ia64 as you said, both domU and
domVTI 
>> failed due to this change.
> 
> The first patch that you work around seems okay to me. That is, it 
> seems correct that we make initial reservation exclude
'getDomainMemory 
> headroom'. Shouldn't ia64 reserve extra memory as it needs it, as x86

> does,  rather than up front?
> 
> The second bit of your workaround, which applies to getDomainMemory:

> I'll wait and see if Charles has anything to say, but otherwise I'll

> remove the code that adds the extra slack entirely.

I think we have a more general problem here.

Xen, historically, hasn't overcommitted memory.  But with shadow page
tables and HVM, that's not really true, is it?

Suppose I start up a 256 MB HVM domain running, say, a forking web
server.  How much physical RAM does this take?  Depends on the load,
doesn't it?

Unless I'm missing something, there is no "big enough" amount of slack,
if you care about reliability.  With Yunhong's BUG -> domain_crash
patch, the box shouldn't crash, but the domain still might.

In shadow32.c, I see a FIXME comment that refers to "shadow flush". 
Even if such things are done, can you put an upper limit on the runtime
memory overhead for an HVM domain?


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