Re: [Xen-devel] [PATCH 2/2] libxl: xl mem-set should not enforce memory limits

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

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.

Ian.



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