[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [Xen-users] Xen memory allocation for dom0 and domU



On Wed, 2015-02-04 at 16:51 +0000, Jan Beulich wrote:
> >>> On 04.02.15 at 17:41, <Ian.Campbell@xxxxxxxxxx> wrote:
> > I originally used to think that domheap allocations would fall back to
> > the xenheap if the domheap was exhausted, but I think I was mistaken in
> > that.
> 
> That's an arch choice actually - there are two variants of the Xen
> heap allocation function.

Ah yes, I keep forgetting about the split which was added to the !
CONFIG_SEPARATE_XENHEAP case recently for x86.

arm32 currently uses CONFIG_SEPARATE_XENHEAP, I don't think it is worth
switching since arm32 will never have truly enormous amounts of RAM I
don't think, plus I'd quite like to be able to backport at least some
aspect of this patch (e.g. the cmdline option if not the change to the
defaults).

arm64 uses !CONFIG_SEPARATE_XENHEAP but doesn't currently register any
RAM above the xenheap_bits limit. We probably will at some point,
although due to the lack of PV guests we have more hypervisor address
space to use for 1:1 than x86 does.

> > Patch for all this below. Jan, I don't think there is any (possibly
> > historical on x86_32) x86 option we should be trying to be consistent
> > with.
> 
> On x86-32 it was always fixed 16M. On x86-64 we had a
> "xenheap_megabytes=" option before the sharing of the pools
> got introduced.

I suppose I should use the same thing for at least some sort of
consistency -- it's not like being able to set the xenheap at
sub-megabyte granularity is going to be very useful...

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.