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] RE: Ballooning up

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.


Xen-devel mailing list

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