From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Rzeszutek Wilk Subject: Re: [PATCH 2/2] libxl: xl mem-set should not enforce memory limits Date: Sat, 16 Mar 2013 09:37:10 -0400 Message-ID: <20130316133709.GA7297@konrad-lan.dumpdata.com> References: <1363364702-12885-1-git-send-email-daniel.kiper@oracle.com> <1363364702-12885-3-git-send-email-daniel.kiper@oracle.com> <1363365173.520.33.camel@zakaz.uk.xensource.com> <20130315170700.GE12758@debian70-amd64.local.net-space.pl> <20803.21983.665377.198905@mariner.uk.xensource.com> <20130315172607.GA14315@phenom.dumpdata.com> <1363377660.22324.3.camel@dagon.hellion.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <1363377660.22324.3.camel@dagon.hellion.org.uk> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Campbell Cc: Daniel Kiper , "xen-devel@lists.xensource.com" , Ian Jackson , Konrad Rzeszutek Wilk List-Id: xen-devel@lists.xenproject.org On Fri, Mar 15, 2013 at 08:01:00PM +0000, Ian Campbell wrote: > On Fri, 2013-03-15 at 17:26 +0000, Konrad Rzeszutek Wilk wrote: > > On Fri, Mar 15, 2013 at 05:09:51PM +0000, Ian Jackson wrote: > > > Daniel Kiper writes ("Re: [PATCH 2/2] libxl: xl mem-set should not enforce memory limits"): > > > > I think that xl mem-max should be used to enforce limits. If admin > > > > would like to enforce "hard" limit it should call xl mem-set and > > > > xl mem-max in sequence. If we would like to leave old xl mem-set > > > > behavior we should change comment for this command because now > > > > it does not mention anythig about limit enforcement. Or we should > > > > add an option which explicitly disables memory limit enforment > > > > (this behavior is in line with xm mem-set behavior). > > > > > > I think this conversation is related to the fact that at Oracle you > > > have a different model of the Xen memory allocation model to everyone > > > else. > > > > Daniel is trying to fix an bug that Linux kernel is tripping over > > b/c of this. Look at the converstation and patch that Daniel posted > > a week ago for the Linux kernel. > > It would be useful to mention (or at least) the rationale for a change > such as this in the commit message. > > However that's rather moot in this case because the rationale is surely > wrong. Linux (and indeed balloon drivers generally) are expected to > behave correctly whether the toolstack chooses to be enforcing or > non-enforcing regarding the balloon target. So you can't "fix" the > kernel by simply mandating that all toolstacks are non-enforcing, sorry. > > > > Outside Oracle, guests are supposed to aim for the balloon target and > > > are not permitted to exceed it (when ballooning up) or to regress > > > (when ballooning down). > > > > s/Oracle/Xend/. As Xend had this distinction. 'xm mem-set' would only set > > the target. 'xm mem-max' on the other hand would enforce the limit. > > > > Daniel is just bringing this behavior to 'xl'. > > xl deliberately deviated from xend on this point. Ah, I did not dig deep enough in the git annotate to see if there was a story behind it. Perhaps then it would make sense to do two things: 1). Add a comment in the code explicitly mentioning it. 2). If we really want to provide an Xend-type behavior add an global configuration value that is called "xend-backwarts=1' ? That way we can fit all the other stuff that is inconsistent underneath that (such as timer_mode changing from number to string, etc). And as part of this global value also explain in the docs what those inconsistencies are? > > Ian. > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel >