From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Campbell Subject: Re: [Xen-users] Xen memory allocation for dom0 and domU Date: Thu, 5 Feb 2015 10:16:26 +0000 Message-ID: <1423131386.24924.59.camel@citrix.com> References: <1423044595.17711.12.camel@citrix.com> <1423061748.24924.10.camel@citrix.com> <1423068085.24924.36.camel@citrix.com> <54D25C19020000780005CFBA@mail.emea.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <54D25C19020000780005CFBA@mail.emea.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich Cc: xen-users@lists.xen.org, StefanoStabellini , Tim Deegan , Jintack Lim , xen-devel List-Id: xen-devel@lists.xenproject.org On Wed, 2015-02-04 at 16:51 +0000, Jan Beulich wrote: > >>> On 04.02.15 at 17:41, 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.