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

To: Daniel Kiper <dkiper@xxxxxxxxxxxx>
Subject: Re: Re: [Xen-devel] Balloon driver for Linux/HVM
From: Chu Rui <ruichu@xxxxxxxxx>
Date: Sat, 20 Nov 2010 00:53:17 +0800
Cc: Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>, Xen-devel@xxxxxxxxxxxxxxxxxxx, jeremy@xxxxxxxx
Delivery-date: Fri, 19 Nov 2010 08:56:10 -0800
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=4XcO9gm9cTTOMfJTwqR9FhPjLiK8saVwj8fXostu6RI=; b=rStke3sLk3V6RFH0wmOupIDmRXnNzmqirRw1GlHapo7DlQqNf5CbR6Nw4+SX/iCrF4 6NyWgM8PxH/mac7Mm2dU5dHkscEh2lppcgbndEX0dKRVSO4ZAvH6mreZnl6scTgYFn0j t/eOzr3YkuoE6/mMKDa3pWkhbhBZBmdfhHi54=
Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=UOShBRNC7idWXmukJ4WS4E8HZxOiuhJMprh7Q2CF4DyeptafF6hLPIgXAdoFh7hAoq I+WEez3B+P9ZCJWNZB0/a3AiHfKHjs/1kTQSg1KCdLBy89lwY/XF0VI5Osz9NEq1tSRF jhvm3S0KMu1HDGgFuCfMEUkhdhLjkqBImF5wQ=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20101118175202.GA5772@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
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: <AANLkTimG5Z3FFrKc21Mtfg-q3eF-aEPEeWZ1cfEDqB7D@xxxxxxxxxxxxxx> <alpine.DEB.2.00.1011161133350.2373@kaball-desktop> <1ae18b.16279.12c547ff769.Coremail.topperxin@xxxxxxx> <AANLkTinEEc=3rFaoWBPrD4zrGU_dqR5s4rmW74jJH543@xxxxxxxxxxxxxx> <AANLkTimgiR1a_BYQiTLK=5pKtfqH7LNaS2CNgYAimpeO@xxxxxxxxxxxxxx> <AANLkTim6MWmcLOJrAjf5K9ydAUGXuOnbw-0KGvLqACtn@xxxxxxxxxxxxxx> <AANLkTi=5Vzv9Jh5kdKN55WVak9Y5Axy7tq60RYJCe-7G@xxxxxxxxxxxxxx> <91b507aa-bf3d-4218-9b7f-65332a4ab7cc@default> <20101118175202.GA5772@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
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 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 ???


Xen-devel mailing list