From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dan Magenheimer Subject: Re: [PATCH 05 of 23] libxl: drop 8M slack for PV guests Date: Tue, 21 Feb 2012 07:27:32 -0800 (PST) Message-ID: <2b417c3e-8bfa-4c6e-9200-94bf34c02e17@default> 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 , Stefano Stabellini Cc: xen-devel@lists.xensource.com, Ian Jackson , Dave Scott List-Id: xen-devel@lists.xenproject.org > From: Ian Campbell [mailto:Ian.Campbell@citrix.com] > Subject: Re: [Xen-devel] [PATCH 05 of 23] libxl: drop 8M slack for PV guests > > 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. Hmmm... this adds a small, but not trivial, performance advantage to xl over xm/xend, at least for small memory guests. Might be a nice second-tier bullet for the 4.2/xl release notes... "better performance" always encourages people to move from old-to-new quicker even when it is hard to quantify or measure.