#23 - Remove arbitrary LIBXL_MAXMEM_CONSTANT from libxl, see what breaks

Owner: Ian Campbell <Ian.Campbell@citrix.com>

Date: Thu Nov 7 11:15:02 2013

Last Update: Thu Nov 7 11:15:02 2013

Severity: normal

Affects:

State: Open

[ Retrieve as mbox ]


From: Ian Campbell <Ian.Campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: ian.jackson@eu.citrix.com, Stefano Stabellini <stefano.stabellini@citrix.com>, xen-devel@lists.xen.org, Jon Ludlam <jonathan.ludlam@eu.citrix.com>, Dave Scott <Dave.Scott@eu.citrix.com>, Wei Liu <wei.liu2@citrix.com>
Subject: Re: [Xen-devel] [PATCH V3 1/5] libxl: bump LIBXL_MAXMEM_CONSTANT to 2048
Date: Thu, 7 Nov 2013 11:03:28 +0000
Message-ID: <1383822208.26213.173.camel@kazak.uk.xensource.com>

[ Reply to this message; Retrieve Raw Message; Archives: marc.info, gmane ]

create !
title it Remove arbitrary LIBXL_MAXMEM_CONSTANT from libxl, see what breaks
thanks

On Wed, 2013-11-06 at 18:04 +0000, Stefano Stabellini wrote:
> > > > > Happened to come across this when I was looking at other problem.
> > > > > 
> > > > > http://lists.xen.org/archives/html/xen-devel/2009-12/msg00401.html
> > > > > 
> > > > > It looks like that constant was never intended to use in the way it is
> > > > > now. Hah.
> > > > 
> > > > Indeed not.
> > > > 
> > > > I vaguely recall that the xapi folks add a bit of slack to the domain
> > > > size while they are doing the calculation to see if it fit will on the
> > > > host, but not actually when they build the domain. (note that this
> > > > therefore only matters for the domain being built, and not cumulatively
> > > > for all domains, which makes a difference to the overall overheads on
> > > > the system). We could try switching to a model like that and see what
> > > > breaks I guess?
> > > > 
> > > > I've CC'd a couple of xapi folks so they can correct my no doubt faulty
> > > > memory ;-)
> > > > Ian.
> > > 
> > > Xapi experts, any thought?
> > 
> > Andy Cooper told me on IRC
> >         Xapi adds the slack when building the domain.
> > 
> > Apparently not doing so cause unspecified fallout. Which isn't to say
> > that's xapi specific and xl would be fine.
> 
> Yeah.. theoretically I think that we shouldn't have that constat at all.
> In practice it could cause stability issues, maybe difficult to narrow
> down. Maybe we should remember to remove it at the beginning of the next
> development cycle and see what breaks? Keeping in mind that OSSTests is
> really unlikely to find any of these issues, we should probably try to
> get the community more involved with the testing.

The reasons for keeping it are based mostly on folklore rather than an
actual understanding of the issues, which may not even be real, and it's
wasting (cumulatively) a fair bit of RAM.

But waiting until early in the 4.5 cycle is probably a good idea.

I've created a bug (with this mail) to remind us to do this.

Ian.


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