All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Jeremy Fitzhardinge <jeremy@goop.org>
Cc: Dan Magenheimer <dan.magenheimer@oracle.com>,
	"Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Konrad Wilk <konrad.wilk@oracle.com>Stefano,
	Daniel Kiper <dkiper@net-space.pl>
Subject: Re: RE: Ballooning up
Date: Wed, 15 Sep 2010 08:13:06 +0100	[thread overview]
Message-ID: <1284534786.15518.207.camel@localhost.localdomain> (raw)
In-Reply-To: <4C8FF18D.4000900@goop.org>

On Tue, 2010-09-14 at 23:05 +0100, Jeremy Fitzhardinge wrote: 
> On 09/14/2010 08:06 AM, Dan Magenheimer wrote:
> >> true, if you don't intend to balloon up, there's no point wasting
> >> memory on unused page structures.
> > I think this is the key.  If dom0_mem is NOT specified, dom0
> > launches with (essentially) all the physical memory of the
> > machine, page tables are allocated in dom0 to map all of physical
> > memory, and auto-ballooning is necessary to launch guests.
> >
> > If dom0_mem IS specified, it is often a much smaller number
> > than size of physical memory; why waste ~1.5% of physical memory
> > on page structures that will never be used?
> >
> > If someone wants to add an option to augment dom0_mem to allow
> > memory-up-ballooning of dom0 above dom0_mem (and can justify
> > a reason why some user might ever use this functionality),
> > that's fine.  But let's not change the definition of the
> > dom0_mem option just because a bug fix happens to make it
> > possible.
> 
> Technically (pedantically), the meaning of dom0_mem is unchanged - it
> sets the initial number of pages given to the domain, and is
> functionally identical to the normal "memory" parameter in a domU config
> file.  The difference is that we're now paying attention to the E820
> map, which is set by maxmem= in domU, but is the hardware/BIOS one in dom0.
> 
> I'm not sure what I'm doing that's different to the xenolinux kernels; I
> guess they hack up the whole memory init path more aggressively.  But
> the pvops behaviour is more or less the straightforward outcome of
> looking at the Xen-provided E820 and reserving the gaps between the
> actual page count and the memory described therein.

xenolinux treats the XENMEM_memory_map and XENMEM_machine_memory_map as
separate things in some wierd split-brain understanding of the physical
address space. Try looking in /proc/iomem on a xenolinux kernel -- IIRC
it has a mish-mash of both address spaces in it...

What PVops does is far more sane.

Ian.

  reply	other threads:[~2010-09-15  7:13 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
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 [this message]
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=1284534786.15518.207.camel@localhost.localdomain \
    --to=ian.campbell@citrix.com \
    --cc=Stefano.Stabellini@eu.citrix.com \
    --cc=Xen-devel@lists.xensource.com \
    --cc=dan.magenheimer@oracle.com \
    --cc=jeremy@goop.org \
    --cc=konrad.wilk@oracle.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.