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>
> > 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 inAs I understrand (if I am wrong please correct me) in last sentence
> 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.
(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
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.
As we agreed ealier sometimes it is better to return memory to the
> 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.
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 ???
Xen-devel mailing list