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


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

To: "Keir Fraser" <Keir.Fraser@xxxxxxxxxxxx>
Subject: [Xen-devel] RE: [PATCH][BALLOON] Fix minimum target
From: "Puthiyaparambil, Aravindh" <aravindh.puthiyaparambil@xxxxxxxxxx>
Date: Sat, 27 May 2006 22:01:07 -0400
Cc: Ky Srinivasan <KSrinivasan@xxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx, "Carb, Brian A" <Brian.Carb@xxxxxxxxxx>
Delivery-date: Sat, 27 May 2006 19:01:57 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
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
Thread-index: AcaB4CEWMEta9MOmRHSOWujH+tVY6gAGUKVQ
Thread-topic: [PATCH][BALLOON] Fix minimum target
> ballooning on other systems then I think we'll have to wait for
> to implement a more dynamic scheme (e.g., by hooking off the
> OOM/low-memory paths, or by slowly allocating memory only when we can
> see a reasonable amount of pages available on the free lists).

>From the little code reading I have done, your second option seems
better. Once the code goes down the OOM path the system is already in a
shaky unstable state. The balloon driver has to be made to back off way
before that. I have been meaning to try and look into this. I will try
and do so. 

> I'm rather doubtful that a really good static estimate can be derived,
> since it depends so much on particular details of kernel memory usage.

I agree.

> Given the results of these experiments I'm tempted to remove the 2%
> minimum that is already in the tree -- vendors can make their own
> if they have a better idea of what works for their particular kernel
> setups.

I second this opinion. I think it is better if you remove the 2%
minimum. It really serves no purpose in the majority of situations.


Xen-devel mailing list