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

[Chu Rui <ruichu@xxxxxxxxx>]

Sorry for the misleading statements before.

The balloon, as my point of view, has the problems as follows:

1. cannot deflate to a "negative" size. therefore the guest swapping will become a problem.

2. long reactive time.

While the advantage is that it need not any guest os modification.

 

tmem solves the problem 1 and 2 well, and mem-hotplug at least solves the former.

Unfortunately both of them need os modification, so I have to select balloon.

I wonder if we can reduce the influence of guest swapping, using dom0/host caching, to cache the swapped pages, if dom0/host have extra memory.

The reactive time, if not too long, maybe tolerable if we temporarily suspend the guest with both a big balloon and instant memory requirments.

 

Sincerely thanks for all of you.

2010/11/19 Daniel Kiper <dkiper@xxxxxxxxxxxx>

Hi,

> > On Wed, Nov 17, 2010 at 07:50:18PM +0800, Chu Rui wrote:

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

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

As I understrand (if I am wrong please correct me) in last sentence
(please look above) Chu stated that balloon driver could not expand
memory above limit declared at boot (which is true). That is why
I mentioned about memory hotplug which is a solution for problem
described above.

1) Now it is true, however it is easy to change that (I sent
  you an proposal which we discussed a bit).

2) It is true if maxmem is set above memory limit available for host.
  If it is set below then it does not pose a problem for host
  because guest could not allocate more memory than maxmem.

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

As we agreed ealier sometimes it is better to return memory to the
system "directly" than allocate it as a backend for swap. I written
PoC (with some suggestions from you) which works and cope very good
with high memory demands. However, it is a long way (to some extent)
to fully working implementation containing all features (ballooning,
tmem and memory hotplug). I could do that. However at the beginnig
we should agree on which kernel version I start development.
For me it looks that git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git
repository, xen/balloon head is the best. What do you think about that ???

Daniel

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