From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Campbell Subject: Re: [PATCH DOCDAY] xen: write a high level description of the sub-arch choices for heap layout Date: Wed, 30 Sep 2015 12:28:30 +0100 Message-ID: <1443612510.16718.188.camel@citrix.com> References: <1443608566-8382-1-git-send-email-ian.campbell@citrix.com> <560BC30E.4050507@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <560BC30E.4050507@citrix.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: Andrew Cooper , xen-devel@lists.xen.org, jbeulich@suse.com List-Id: xen-devel@lists.xenproject.org On Wed, 2015-09-30 at 12:10 +0100, Andrew Cooper wrote: > + * > > + * CONFIG_SEPARATE_XENHEAP=n W/ ONLY DIRECT MAP OF ONLY PARTIAL RAM > > + * > > + * There is a single heap, but only the beginning (up to some > > + * threshold) is covered by a permanent contiguous mapping. > > Perhaps avoid the use of "beginning" here? It is just an implementation > detail of the only current example. It's an implementation detail which is currently exposed to the arch code via the need to use xenheap_max_mfn() (or not) and the shape of that API though. > In some copious free time, I want to see about striding the x86 > directmap across NUMA nodes (to allow NUMA-local xenheap allocations > even on large boxes), at which point it won't be linear from the start. In which case this bit of doc would need some adjustments over and above avoiding the work beginning I think, at least to adjust to the replacement for xenheap_max_mfn(). Ian.