xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: David Vrabel <david.vrabel@citrix.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: [RFC] limit dom0 memory using Xen's dom0_mem command line option
Date: Tue, 16 Aug 2011 09:33:02 -0400	[thread overview]
Message-ID: <20110816133302.GA30261@dumpdata.com> (raw)
In-Reply-To: <1313488838-28809-1-git-send-email-david.vrabel@citrix.com>

On Tue, Aug 16, 2011 at 11:00:35AM +0100, David Vrabel wrote:
> This set of patches limits the amount of memory dom0 can use by using
> Xen's dom0_mem=max:NNN command line option.  This can make extra
> memory available because less memory is wasted on page tables that are
> never used and fewer pages are reserved for low memory situations.
> 
> In addition, the extra pages can be in two regions which allows more
> low memory to be available if dom0 intially starts with less than 1
> GiB.
> 
> Xen requires the patch "x86: use 'dom0_mem' to limit the number of
> pages for dom0" to provide the correct information in the
> XENMEM_maximum_reservation memory op.
> 
> Instead of this approach would it be better to limit dom0 memory to
> the initial number pages and use the recently added memory hotplug
> support in the balloon driver for all reservation increases?

I was thinking about it, but one interesting thing that Stefano and Jeremy
pointed out is that we need to have some amount of "reserved" memory
at the start of the machine. We need that "reserved" memory so that the
Linux guest can allocate 'struct page' for non-existent memory - and then
those 'struct page' we can use for sharing pages across domains.

So if you use the memory hotplug, we might not have that
reserved memory during bootup - and we need it. Perhaps there is
a way to compromise on this?

      parent reply	other threads:[~2011-08-16 13:33 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-08-16 10:00 [RFC] limit dom0 memory using Xen's dom0_mem command line option David Vrabel
2011-08-16 10:00 ` [PATCH 1/3] xen: allow balloon driver to use more than one memory region David Vrabel
2011-08-16 13:38   ` Konrad Rzeszutek Wilk
2011-08-16 14:21     ` David Vrabel
2011-08-16 14:48       ` Konrad Rzeszutek Wilk
2011-08-16 15:03         ` David Vrabel
2011-08-16 10:00 ` [PATCH 2/3] xen: allow extra memory to be two regions David Vrabel
2011-08-16 13:48   ` Konrad Rzeszutek Wilk
2011-08-16 14:33     ` David Vrabel
2011-08-16 14:48       ` Konrad Rzeszutek Wilk
2011-08-16 15:03         ` David Vrabel
2011-08-16 15:36           ` Konrad Rzeszutek Wilk
2011-08-22 13:55             ` Konrad Rzeszutek Wilk
2011-08-22 14:01               ` David Vrabel
2011-08-16 10:00 ` [PATCH 3/3] xen: use maximum reservation to limit dom0 memory David Vrabel
2011-08-16 13:53   ` Konrad Rzeszutek Wilk
2011-08-16 14:41     ` David Vrabel
2011-08-16 14:54       ` Konrad Rzeszutek Wilk
2011-08-16 14:50     ` Konrad Rzeszutek Wilk
2011-08-16 13:33 ` Konrad Rzeszutek Wilk [this message]

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=20110816133302.GA30261@dumpdata.com \
    --to=konrad.wilk@oracle.com \
    --cc=david.vrabel@citrix.com \
    --cc=xen-devel@lists.xensource.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).