Re: [Xen-devel] [PATCH 05 of 23] libxl: drop 8M slack for PV guests

[Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>]

> From: Ian Campbell [mailto:Ian.Campbell@xxxxxxxxxx]
> 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.

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