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


[Xen-devel] Ballooning up

To: "Xen-devel@xxxxxxxxxxxxxxxxxxx" <Xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: [Xen-devel] Ballooning up
From: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Date: Tue, 07 Sep 2010 18:36:03 +1000
Cc: Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>, Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>, Daniel Kiper <dkiper@xxxxxxxxxxxx>, Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>
Delivery-date: Tue, 07 Sep 2010 01:38:03 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20100806 Fedora/3.1.2-1.fc13 Lightning/1.0b2pre Thunderbird/3.1.2
 I finally got around to implementing "ballooning up" in the pvops
kernels.  Now if you start a domain with "memory=X maxmem=Y", the domain
will start with X MB of memory, but you can use "x[ml] mem-set" to
expand the domain up to Y.

This relies on the toolstack setting the E820 map for the domain with an
E820_RAM region which goes beyond xen_start_info->nr_pages.  When the
domain starts up and sees this, then it adds the extra pages to the
kernel's E820 map, but marks them reserved.  This causes the kernel to
allocate page structures for that memory, but it doesn't attempt to
allocate or use them.  When the balloon driver starts, it adds those
pages to the list of ballooned out pages, and everything works as
expected from there.

This also means that you can fail to boot if Y is many times larger than
X, because the kernel's memory gets filled with page structures.  This
can be particularly acute on 32-bit domains, as the page structures must
be in low memory.

As a side-effect, it also works for dom0.  If you set dom0_mem on the
Xen command line, then nr_pages is limited to that value, but the kernel
can still see the system's real E820 map, and therefore adds all the
system's memory to its own balloon driver, potentially allowing dom0 to
expand up to take all physical memory.

However, this may caused bad side-effects if your system memory is much
larger than your dom0_mem, especially if you use a 32-bit dom0.  I may
need to add a kernel command line option to limit the max initial
balloon size to mitigate this...

Also, any unused pages released at boot time (because they fall into
holes between E820 regions) are also added to the balloon, so they can
be ballooned back in again (this doesn't happen automatically, however).

(Konrad, the infrastructure put in place also makes it very easy for the
kernel to punch a PCI hole in its own E820 maps to leave space for
passthrough devices if we want.  Or if the tools pass in an E820 map
with a suitable hole, then it will be automatically honoured.)

These changes are in xen/next-2.6.32 for the moment.  I'll merge them
into xen/stable-2.6.32.x if they don't cause too many problems.

Also, there's currently a bug in the xl toolset which causes it to
ignore the maxmem domain parameter.  Stefano has a pending patch to fix

I haven't tested this with xm/xend, XCP, Xen Client or Xen Server -
please let me know how it goes.


Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>