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

[Chu Rui <ruichu@xxxxxxxxx>]

Exactly, Dan.

Since most of our guests are running Windows, it is hard to make a binary patch on Windows, to make tmem working (Although tmem perfectly solves the problem of guest swapping). I am afraid the memory hotplug does not work as well in Windows guest.

Thus the only choise for me is balloon, is it?

2010/11/18 Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>

> 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.

Dan

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