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: 答复: [Xen-devel] Xen balloon driver discuss

To: George Dunlap <George.Dunlap@xxxxxxxxxxxxx>
Subject: Re: 答复: [Xen-devel] Xen balloon driver discuss
From: Chu Rui <ruichu@xxxxxxxxx>
Date: Tue, 30 Nov 2010 11:51:45 +0800
Cc: tinnycloud <tinnycloud@xxxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>
Delivery-date: Mon, 29 Nov 2010 19:53:38 -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=eU8cTgsL8Kw0tuRv2Br03S5hYXMfSkzssXYumnpQcHk=; b=Me+B7McemxJ57ZoHmrqpSm0mEIgHVNrei/T8tBlUd8eXa7dWXZNfkHs2jbrC24qd0p SG91L6OTVzf7n9Eq05i1oInEygSg07GEzzga+Ce8HAZ/h6JBfZfMAuPcVvx5EaPlU2rr V5tUvPeEyL3QT2AAm14BZSvto5dT75LcPNn3U=
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=M3pvNg6vbselycjqOi3M3CX6rDtiefYaSfrOJVgYJkTRRj55sE51dNkFl7v9xFiUC8 W30Pq6xlIb8VwMVuEh51iWlPEvYx9uStkYTUdosSTAJuxiAz+mNVdlaxg0qR/LjplpA8 Uka866HyMEIUMu8l7sGlAJ02v7DoYDacRbN90=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4CF38C2F.3020605@xxxxxxxxxxxxx>
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: <SNT0-MC3-F148nSuKiM000aac29@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <BLU157-ds6B75FFC7D37D79C68C5B4DA3C0@xxxxxxx> <AANLkTi=zHP5fQLtHN5xva0e8FSVistd8Se8Ys2nrqh=t@xxxxxxxxxxxxxx> <BLU157-ds19D073F9CDA3C196544C34DA240@xxxxxxx> <4CF38C2F.3020605@xxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
I also think it is a little strange in current PoD implementation, different with my image.
In my mind, as tinnycloud mentioned, the PoD cache should be a pool as large as the idle memory in VMM, and shared by all guests. If a guest usages was always smaller than the predefined PoD cache size, the unused part could be appropriated for others. On the contrary, If a guest balloon was delayed  to be started, the VMM should populate more memory to satisfy it (supposing the VMM has enough memory).
In current PoD, the balloon should be started as soon as possbile, otherwise the guest will be crashed after the PoD cache is exhausted(supposing the emergency sweep does not work). That's dangerous, although in most cases it works well.
George, I wonder why do you implement it as this? It looks better to used a resilient PoD cache, intead of a fixed one. Your wonderful work was appreciated, I just want to know your thought.

在 2010年11月29日 下午7:19,George Dunlap <George.Dunlap@xxxxxxxxxxxxx>写道:
On 29/11/10 10:55, tinnycloud wrote:
> So that is, if we run out of PoD cache before balloon works, Xen will
> crash domain(goto out_of_memory),

That's right; PoD is only meant to allow a guest to run from boot until
the balloon driver can load.  It's to allow a guest to "boot ballooned."

> and at this situation, domain U swap(dom U can’t use swap memory) is not
> available , right?

I don't believe swap and PoD are integrated at the moment, no.

> And when balloon actually works, the pod cached will finally decrease to
> 0, and no longer be used any more, right?

Conceptually, yes.  What actually happens is that ballooning will reduce
it so that pod_entries==cache_size.  Entries will stay PoD until the
guest touches them.  It's likely that eventually the guest will touch
all the pages, at which point the PoD cache will be 0.

> could we use this method to implement a tmem like memory overcommit?

PoD does require guest knowledge -- it requires the balloon driver to be
loaded soon after boot so the so the guest will limit its memory usage.
 It also doesn't allow overcommit.  Memory in the PoD cache is already
allocated to the VM, and can't be used for something else.

You can't to overcommit without either:
* The guest knowing that it might not get the memory back, and being OK
with that (tmem), or
* Swapping, which doesn't require PoD at all.

If you're thinking about scanning for zero pages and automatically
reclaiming them, for instance, you have to be able to deal with a
situation where the guest decides to use a page you've reclaimed but
you've already given your last free page to someone else, and there are
no more zero pages anywhere on the system.  That would mean either just
pausing the VM indefinitely, or choosing another guest page to swap out.


> *From:* Chu Rui [mailto:ruichu@xxxxxxxxx]
> *TO:* tinnycloud
> *CC:* xen-devel@xxxxxxxxxxxxxxxxxxx; George.Dunlap@xxxxxxxxxxxxx;
> dan.magenheimer@xxxxxxxxxx
> *Subject:* Re: [Xen-devel] Xen balloon driver discuss
> I am also interested with tinnycloud's problem.
> It looks that the pod cache has been used up like this:
> if ( p2md->pod.count == 0 )
> goto out_of_memory;
> George, would you please take a look on this problem, and, if possbile,
> tell a little more about what does PoD cache mean? Is it a memory pool
> for PoD allocation?

Xen-devel mailing list