WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

To: Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>
Subject: Re: [Xen-devel] Linux Xen balloon driver "minimum target"
From: George Dunlap <George.Dunlap@xxxxxxxxxxxxx>
Date: Mon, 21 Jun 2010 11:03:04 +0100
Cc: Jeremy Fitzhardinge <jeremy@xxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx, Dave Scott <Dave.Scott@xxxxxxxxxxxxx>, George Shuklin <nge@xxxxxxxx>, Jan Beulich <JBeulich@xxxxxxxxxx>, Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Delivery-date: Mon, 21 Jun 2010 03:05:51 -0700
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=ui0lqzPWtOG9fbL48semY89YBeA/s8emI29kz04nKGw=; b=AW9A06HU/xCar4yqDTBCafciOJRAulu18jNTlFDMPnSY9wAJ7q3XnrzzOMTORZvMEE wXqsvriBAa9xf3tPONaKLfMTrGlOzqGzZuSH09mIQYy4LyVeSuYntcd3VxEfPT/a9+kz r/yuQOuJFPz4Tqp72Tvi97HB2jaVeB0itsYV0=
Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=Zt1iBUYkEOtRS9hHeRo72wSZYYHHkKH9Mc89bmRdw11eMbaV5/NEBm7aTcyR9ADKEM WWDtG4i2ggfWnyCmPxYDzzgP85MYrpgKhNBTQDGwIpCAiOOptgXE5jlPlbQcUVJ3tdYs o60UHG3kTRfEyNrWIbfueqmgiShnohCREntvk=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <bdd17f28-12d7-4a01-beae-4d8c291d8194@default>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <bdd17f28-12d7-4a01-beae-4d8c291d8194@default>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
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

<Prev in Thread] Current Thread [Next in Thread>