From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Campbell Subject: Re: freemem-slack and large memory environments Date: Tue, 24 Feb 2015 16:54:01 +0000 Message-ID: <1424796841.20243.5.camel@citrix.com> References: <4321015.nah3j6dvJq@mlatimer1.dnsdhcp.provo.novell.com> <2094469.vaaEIflRW2@mlatimer1.dnsdhcp.provo.novell.com> <1424268653.27775.68.camel@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Stefano Stabellini Cc: wei.liu2@citrix.com, ian.jackson@eu.citrix.com, Mike Latimer , xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org 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 > > > >