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/
Home Products Support Community News


RE: Re: [Xen-devel] Balloon driver for Linux/HVM

> From: Daniel Kiper [mailto:dkiper@xxxxxxxxxxxx]
> Sent: Wednesday, November 17, 2010 6:04 AM
> To: Chu Rui
> Cc: jeremy@xxxxxxxx; Dan Magenheimer; Xen-devel@xxxxxxxxxxxxxxxxxxx
> Subject: Re: Re: [Xen-devel] Balloon driver for Linux/HVM
> Hello,
> On Wed, Nov 17, 2010 at 07:50:18PM +0800, Chu Rui wrote:
> > You are right, so balloon is an important tool to adjust the capacity
> of the
> > buffer caches among the guests. But balloon is usually criticized for
> its
> > long reactive time. Would you please tell me how slow it is? Can we
> > temporarily suspend the guest when the balloon deflating speed is not
> as far
> > as required?
> > Furthermore, with HVM, the balloon does not work when the guest is
> short of
> > memory and swapping, even the host has a lot of surplus at that time.
> > Besides promise a large size to the booting guest, it there any
> better way?
> Yes, it is - memory hotplug. Now it is under development. Currently,
> I am waiting for some comments for new version of patch. I will make
> it public when I receive those reviews.

Hi Daniel --

If I am not misunderstanding, memory hotplug (whether it works in
an HVM guest or not) doesn't solve Chu's issue because memory hotplug
either: (1) requires operator intervention or (2) creates denial-of-service
conditions such as a guest maliciously hot-plugging as much memory
as it can.

Chu's stated issue is that ballooning is not responsive enough when
memory demand increases unexpectedly.  Since future memory demand
can never be accurately predicted (only poorly guessed), some
compensating mechanism must be in place to handle the poorly predicted
cases.  That's essentially what tmem is good for.


Xen-devel mailing list