Re: [PATCH V3 1/5] libxl: bump LIBXL_MAXMEM_CONSTANT to 2048

[Wei Liu <wei.liu2@citrix.com>]

On Fri, Nov 01, 2013 at 04:23:04PM +0000, Ian Campbell wrote:
> On Fri, 2013-11-01 at 16:10 +0000, Wei Liu wrote:
> > On Fri, Nov 01, 2013 at 04:02:17PM +0000, Ian Campbell wrote:
> > > On Tue, 2013-10-29 at 11:39 +0000, Wei Liu wrote:
> > > > When using OVMF we need to have 1MiB of memory in place for firmware.
> > > > Without this change we have:
> > > > 
> > > > (XEN) HVM128: Loading OVMF ...
> > > > (XEN) page_alloc.c:1460:d128 Over-allocation for domain 128: 33025 > 33024
> > > > (XEN) memory.c:132:d128 Could not allocate order=0 extent: id=128 memflags=0 (0 of 1)
> > > > 
> > > > This is not a fatal error as hvmloader will instead use low memory to
> > > > load OVMF, but it's better to eliminate such error.
> > > > 
> > > > Changing this constant doesn't necessary increase the total amount of
> > > > memory a guest uses because it's just a limit.
> > > 
> > > It will allow a guest to try and use up to 1MB more though, and it
> > > allows this for PV guests as well as HVM guests not using OVMF.
> > > 
> > > There's only a small number of place which use this constant, can we
> > > refactor them into a helper function, which can then be expanded to
> > > include a per-BIOS overhead in addition to this one? The BIOS selection
> > > is stored in xenstore, so that work even for calls which don't have the
> > > domain configuration to hand.
> > > 
> > > (does anyone remember what the existing 1MB is actually for?)
> > > 
> > 
> > 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?

Wei.