From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Vrabel Subject: Re: [PATCH 05 of 23] libxl: drop 8M slack for PV guests Date: Tue, 21 Feb 2012 10:53:01 +0000 Message-ID: <4F43778D.2080507@cantab.net> References: <192eefb9e00e048333b0.1329151971@cosworth.uk.xensource.com> <20290.39907.912639.18195@mariner.uk.xensource.com> <1329819046.25232.69.camel@dagon.hellion.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1329819046.25232.69.camel@dagon.hellion.org.uk> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Campbell Cc: "xen-devel@lists.xensource.com" , Ian Jackson , Dave Scott , Stefano Stabellini List-Id: xen-devel@lists.xenproject.org On 21/02/12 10:10, Ian Campbell wrote: > On Tue, 2012-02-21 at 10:10 +0000, Stefano Stabellini wrote: >> On Mon, 20 Feb 2012, Ian Jackson wrote: >>> Ian Campbell writes ("[Xen-devel] [PATCH 05 of 23] libxl: drop 8M slack for PV guests"): >>>> libxl: drop 8M slack for PV guests. >>>> >>>> As far as I can tell this serves no purpose. I think it relates to the old >>>> 8M to "account for backend allocations" which we used to add. This leaves a bit >>>> of unpopulated space in the Pseudo-physical address space which can be used by >>>> backends when mapping foreign memory. However 8M is not representative of that >>>> any more and modern kernels do not operate in this way anyway. >>>> >>>> I suspect an argument could be made for removing this from the libxl API >>>> altogether but instead lets just set the overhead to 0. >>> >>> I think this is plausible but I'd like to hear from Stefano, who iirc >>> may have some knowledge about the reason for this 8Mb. >> >> It comes from XenD (and XAPI too, if I recall correctly), see this >> comment in tools/python/xen/xend/image.py: > > That doesn't answer the "why" though. > > I think I should just be more assertive since I believe I do actually > know why the 8 is there (or certainly nobody appears to know any > better). I'll update the changelog to read: > > This serves no purpose. It relates to the old 8M to "account for > backend allocations" which we used to add. This leaves a bit of > unpopulated space in the Pseudo-physical address space which can > be used by backends when mapping foreign memory. However 8M is > not representative of that any more and modern kernels do not > operate in this way anyway. Should a similar fix be applied to Xen as well for dom0? Daid