[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



On Wed, 2013-11-06 at 10:32 +0000, Wei Liu wrote:
> 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?

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.

Ian.


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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.