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/
Home Products Support Community News


Re: [Xen-devel] Re: [PATCH][BALLOON] Fix minimum target

To: "Ky Srinivasan" <ksrinivasan@xxxxxxxxxx>
Subject: Re: [Xen-devel] Re: [PATCH][BALLOON] Fix minimum target
From: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Date: Tue, 30 May 2006 16:31:42 +0100
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, Aravindh Puthiyaparambil <aravindh.puthiyaparambil@xxxxxxxxxx>, Brian A Carb <Brian.Carb@xxxxxxxxxx>
Delivery-date: Tue, 30 May 2006 08:32:43 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: Your message of "Tue, 30 May 2006 08:47:25 MDT." <447C22BA.E57C.0030.0@xxxxxxxxxx>
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/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
> The idea was to have in place a structure that allowed for some
> experimentation on exactly what the floor needs to be and what the
> minimum memory slope needs to be.  An earlier version of my patch
> attempted to classify machines based on the maximum amount of memory
> that it would ever handle. For each class the minimum memory was still a
> linear function with the slope and the floor being dependent on the
> maximum amount of memory that the domain would handle. Another approach
> I was considering was to base the amount of minimum memory on the amount
> of free memory a domain has. This strategy may give us a reasonably
> functional system when the domain is ballooned down while it may result
> in a minimum that could be potentially higher than an approach that we
> have been playing with might yield.

I don't believe any static predetermined floor is going to work
well. Basically I expect that any such approach will either:
 A. Exhibit many false negatives (allow ballooning beyond the critical
 point and result in OOM)
 B. Exhibit many false positives (disallow ballooning when it would
 actually be safe)
 C. Be an unmaintainable mess of special cases derived via empirical
 analysis that will not scale or continue to work well moving forward

I'm particularly bothered by B as it is harder to prove that a
particular patch has that problem. But for example, I'm sure a static
floor of 192MB falls squarely into B.

Unless someone convinces me otherwise, I hold out more hope for the
kind of dynamic approach I've been discussing with Aravindh.

 -- Keir

Xen-devel mailing list

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