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

Re: [Xen-devel] freemem-slack and large memory environments



On Tue, 2015-02-24 at 16:06 +0000, Stefano Stabellini wrote:
> > Now that we autodetect the use of dom0_mem and set autoballooning
> > correctly perhaps we should just revert a39b5bc64?
> 
> We could do that and theoretically it makes perfect sense, but it would
> result in an even bigger waste of memory.

Would it, even though we now detect dom0_mem usage and do the right
thing? I thought a39b5bc64 was a workaround for autoballooning=1
in /etc/xen/xl.conf when dom0 was used.


> I think we should either introduce an hard upper limit for
> freemem-slack as Mike suggested, or remove freemem-slack altogether and
> properly fix any issues caused by lack of memory in the system (properly
> account memory usage).
> After all we are just at the beginning of the release cycle, it is the
> right time to do this.

I'm all in favour of someone doing this, similarly to
http://bugs.xenproject.org/xen/bug/23

Who is going to do that (either one)?

Ian.

> 
> 
> > Ian.
> > 
> > > > 
> > > > It seems that there are two approaches to resolve this:
> > > > 
> > > >  - Introduce a hard limit on freemem-slack to avoid unnecessarily large
> > > > reservations
> > > >  - Increase the retry count during domain creation to ensure enough 
> > > > time is
> > > > set aside for any cycles spent freeing memory for freemem-slack (on the 
> > > > test
> > > > machine, doubling the retry count to 6 is the minimum required)
> > > > 
> > > > Which is the best approach (or did I miss something)?
> > > 
> > > Sorry - forgot to CC relevant maintainers.
> > > 
> > > -Mike
> > 
> > 



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