From: Jeremy Fitzhardinge <jeremy@goop.org>
To: Dan Magenheimer <dan.magenheimer@oracle.com>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
Xen-devel@lists.xensource.com, Daniel Kiper <dkiper@net-space.pl>,
Konrad Wilk <konrad.wilk@oracle.com>
Subject: Re: RE: Ballooning up
Date: Mon, 13 Sep 2010 15:51:58 -0700 [thread overview]
Message-ID: <4C8EAB0E.7040407@goop.org> (raw)
In-Reply-To: <54eebb3a-f539-43be-8134-a969a4f671c4@default>
On 09/13/2010 02:17 PM, Dan Magenheimer wrote:
>> 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...
> I would call this dom0 functionality a bug. I think both Citrix
> and Oracle use dom0_mem as a normal boot option for every
> installation and, while I think both employ heuristics to choose
> a larger dom0_mem for larger physical memory, I don't think it
> grows large enough for, say, >256GB physical memory, to accommodate
> the necessarily large number of page tables.
>
> So, I'd vote for NOT allowing dom0 to balloon up to physical
> memory if dom0_mem is specified, and possibly a kernel command
> line option that allows it to grow beyond. Or, possibly, no
> option and never allow dom0 memory to grow beyond dom0_mem
> unless (possibly) it grows with hot-plug.
Yes, its a bit of a problem. The trouble is that the kernel can't
really distinguish the two cases; either way, it sees a Xen-supplied
xen_start_info->nr_pages as the amount of initial memory available, and
an E820 table referring to more RAM beyond that.
I guess there are three options:
1. add a "xen_maxmem" (or something) kernel parameter to override
space specified in the E820 table
2. ignore E820 if its a privileged domain
3. only allow extra memory up to a certain ratio of the base memory
(8x? 16x? 32x?)
I think the third is probably the simplest and least hacky, as it
directly addresses the underlying issue (and prevents domU mishaps as well).
J
next prev parent reply other threads:[~2010-09-13 22:51 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-07 8:36 Ballooning up Jeremy Fitzhardinge
[not found] ` <54eebb3a-f539-43be-8134-a969a4f671c4@default4C8EAB0E.7040407@goop.org>
2010-09-07 10:14 ` Ian Campbell
2010-09-07 13:26 ` Jeremy Fitzhardinge
2010-09-07 14:10 ` Ian Campbell
2010-09-15 21:47 ` Dan Magenheimer
2010-09-15 22:41 ` Jeremy Fitzhardinge
2010-09-13 21:17 ` Dan Magenheimer
2010-09-13 21:39 ` Dan Magenheimer
2010-09-13 23:06 ` Jeremy Fitzhardinge
2010-09-13 22:51 ` Jeremy Fitzhardinge [this message]
2010-09-14 0:22 ` Dan Magenheimer
2010-09-14 0:46 ` Jeremy Fitzhardinge
2010-09-14 15:06 ` Dan Magenheimer
2010-09-14 22:05 ` Jeremy Fitzhardinge
2010-09-15 7:13 ` Ian Campbell
2010-09-14 8:41 ` Jan Beulich
2010-09-14 16:35 ` Jeremy Fitzhardinge
2010-09-14 9:07 ` Ian Campbell
2010-09-14 16:42 ` Jeremy Fitzhardinge
2010-09-15 7:10 ` Ian Campbell
2010-09-15 17:29 ` Jeremy Fitzhardinge
2010-09-15 18:06 ` Dan Magenheimer
2010-09-15 20:29 ` Jeremy Fitzhardinge
2010-09-14 8:34 ` Ian Campbell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4C8EAB0E.7040407@goop.org \
--to=jeremy@goop.org \
--cc=Xen-devel@lists.xensource.com \
--cc=dan.magenheimer@oracle.com \
--cc=dkiper@net-space.pl \
--cc=konrad.wilk@oracle.com \
--cc=stefano.stabellini@eu.citrix.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.