[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |