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] Re: GSoC 2010 - Migration from memory ballooning to memo

To: Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>
Subject: Re: [Xen-devel] Re: GSoC 2010 - Migration from memory ballooning to memory hotplug in Xen
From: Daniel Kiper <dkiper@xxxxxxxxxxxx>
Date: Fri, 9 Jul 2010 17:53:12 +0200
Cc: jeremy@xxxxxxxx, Andi Kleen <andi@xxxxxxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx, Daniel Kiper <dkiper@xxxxxxxxxxxx>, linux-kernel@xxxxxxxxxxxxxxx
Delivery-date: Fri, 09 Jul 2010 08:54:31 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <592dc9b4-d329-4ce3-a5a1-9e6e7044b90c@default>
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: <871vbdr4ey.fsf@xxxxxxxxxxxxxxxxx> <592dc9b4-d329-4ce3-a5a1-9e6e7044b90c@default>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.3.28i
On Thu, Jul 08, 2010 at 04:12:01PM -0700, Dan Magenheimer wrote:
> > From: Andi Kleen [mailto:andi@xxxxxxxxxxxxxx]
> >
> > Daniel Kiper <dkiper@xxxxxxxxxxxx> writes:
> > >
> > > OK, let's go to details. When I was playing with Xen I saw that
> > > ballooning does not give possibility to extend memory over boundary
> > > declared at the start of system. Yes, I know that is by desing
> > however
> > > I thought that it is a limitation which could by very annoing in some
> > > enviroments (I think especially about servers). That is why I decided
> > to
> > > develop some code which remove that one. At the beggining I thought
> > > that it should be replaced by memory hotplyg however after some test
> > > and discussion with Jeremy we decided to link balooning (for memory
> > > removal) with memory hotplug (for extending memory above boundary
> > > declared at the startup of system). Additionaly, we decided to
> > implement
> > > this solution for Linux Xen gustes in all forms (PV/i386,x86_64 and
> > > HVM/i386,x86_64).
> >
> > While you can do that the value is not very large because you
> > could just start the guests with more memory, but ballooned in
> > the first place (so that they don't actually use it)
> >
> > The only advantage of using memory hotadd is that the mem_map doesn't
> > need to be pre-allocated, but that's only a few percent of the memory.
> >
> > So it would only help if you want to add gigantic amounts of memory
> > to a VM (like >20-30x of what it already has).
>
> One can envision a scenario where a cloud customer launches a
> business-critical VM with some reasonably large "maxmem" set,
> balloons up to the max, then finds out it isn't enough after
> all and would like to avoid rebooting.  Or a cloud provider
> might charge for a specific maxmem, but allow the customer
> to increase maxmem if they pay more money.

Dan scenario description is very good (thx). The idea behind this
project was to serve that cases. Maybe some misunderstanding come
from short description of my proposal.

Daniel

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