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] [PATCH] increase initial memory reservation for stubdom

To: "Stefano Stabellini" <stefano.stabellini@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH] increase initial memory reservation for stubdom based HVM domains
From: "Trolle Selander" <trolle.selander@xxxxxxxxx>
Date: Thu, 15 Jan 2009 13:34:36 -0500
Cc: xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Thu, 15 Jan 2009 10:35:05 -0800
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type:references; bh=GWlxMR/bdit0BeulGhrmMlxrcjkU5uY6NpOnBopf2SM=; b=w1w0mpj78+UIQQz7m1wgNpm5SAVy0XEu0uN3Ib+Q0U12E5CWj6sicrDaSq2Z0y+HWF oyjy34nEaFV6x7cwQ9jyLhfApInudqjMTrB0nXHnXnAgtPhwu3SJPJHls/Fc24ug/+2W pvvP+/YlCMkotrLhCg1ZvCdssdHLb4VwhuAbE=
Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:references; b=Qql5KwRJzJCiWbfx9weWIdoFliIU5hHACTyAjxaKqZ/rDCCtnC5TfINZ1ZvZiQME+V hEhRi2yZKt2ooWENjfyLjpOcKsjsxkX0iO+R2H7IP3ym3bXxz5hQZw0yDz3ti8L1hjD+ zMhTt1LTPbIl1m/V/Z/xlJ7LU6sP0I9UNnM2o=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <496F7989.2050702@xxxxxxxxxxxxx>
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: <496F6D8D.9050302@xxxxxxxxxxxxx> <C5952422.2102F%keir.fraser@xxxxxxxxxxxxx> <20090115174422.GB16629@xxxxxxxxxxxxxxxxxxxxxxx> <496F7989.2050702@xxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
For what it's worth, the discussion on qemu-devel is leaning towards not having a hardcoded limit to the amount of assignable vram, and that more than xres * yres * 4 bytes or vram can in fact be useful for a guest. We can of course still enforce a limit - I'd raise it to 32 Megs, taking double-buffering into consideration. Regardless of the arguments on qemu-devel, i think the practical use of any more vram than that is questionable to say the least - but depending on how closely we want to stay in sync with upstream qemu this should perhaps the at least be taken into consideration.

-- Trolle

On Thu, Jan 15, 2009 at 12:59 PM, Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx> wrote:
Samuel Thibault wrote:

> Keir Fraser, le Thu 15 Jan 2009 17:34:26 +0000, a écrit :
>> Doesn't stubdom itself cause the auto-ballooner to be run?
>
> Yes. (and the issue was that here the auto-ballooner doesn't know that
> qemu hasn't taken the 8MB extra ballooned memory for video memory yet)
>
>> Could stubdom add on the extra headroom of the guest its servicing
>> when it requests ballooning? I don't know whether that would be
>> clearer/cleaner than your current patch...
>
> I don't know how that could be done, but it seems better to me.
>

It can be done: instead of requesting 16MB for the videoram (or whatever
is set in the config file) when we create the HVM domain, we request
them when we create the stubdom.
It also seems to me that this approach is cleaner, I'll try to come up
with a patch.

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

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