[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, 6 Nov 2013, Ian Campbell wrote:
> 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.

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.

_______________________________________________
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®.