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

Re: [Xen-devel] Linux Xen balloon driver "minimum target"



It sounds like this safety measure increases reliability; but at the
same time, I'm opposed to safety measures that can't be disabled or
overridden.  Seems like a reasonable solution to me.

 -G

On Fri, Jun 18, 2010 at 4:24 PM, Dan Magenheimer
<dan.magenheimer@xxxxxxxxxx> wrote:
> As recently re-pointed out by George Shuklin:
> http://lists.xensource.com/archives/html/xen-devel/2010-06/msg00849.html
> with brief reply commentary by Keir:
> http://lists.xensource.com/archives/html/xen-devel/2010-06/msg00875.html
>
> the Xen ballooning code in many distros contains a
> "minimum target" to allow a domain to protect itself
> against silly and accidental balloon settings, it being
> frightfully easy for a typo or misunderstanding (e.g.
> an integer intended to represent MB but, oops, the value
> should be given in KB) to result in a guest or dom0 crash.
>
> This code originated from Novell about two years ago:
> http://lists.xensource.com/archives/html/xen-devel/2008-04/msg00143.html
> and, in my experience, eliminated frequent bug reports that
> "xm memset" resulted in unexpected crashes.
>
> This minimum target is a bit over-conservative, especially
> on machines with 1GB-2GB of memory.  Also, the
> "logarithmic function" is applied to different values in
> different kernels, so is in some cases a function of the
> config file's "maxmem" and in some cases a function of "memory".
>
> Because the variations of this code are broad (and, in upstream
> Linux, non-existent), posting a patch doesn't solve the problem.
> So instead, I thought I would open a discussion with my opinions
> and "solution".  We'll keep this on xen-devel for now, but
> perhaps should open the discussion to xen-users as well.
>
> I am in favor of keeping the code AND inserting some form of
> it in the upstream balloon driver.  There are two forms
> of policy it enforces: (1) don't let an admin do something
> REALLY stupid; and (2) "stupid" is dependent on the amount
> of guest physical memory.  While I don't much like (2), I
> don't see a way one can get (1) without (2).
>
> As a partial answer, in my balloon driver implementation
> (to support self-ballooning) I added an additional proc/sysfs
> variable "min_target_kb".  This is set during init to the
> result of the "minimum target" algorithm and, once set,
> is used as the minimum allowed ballooning target.  BUT
> this variable is writable, allowing the safety latch to
> be overridden.  As a result, a system admin must shoot himself
> in the foot before accidentally shooting himself in the head.
>
> Clearly this is still not an ideal solution, but it works
> for me.
>
> Comments?
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel
>

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.