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

Re: [Xen-API] [XCP] Frequently-Asked Questions (FAQ) for Dynamic Memory Control (DMC)


  • To: "xen-api@xxxxxxxxxxxxxxxxxxx" <xen-api@xxxxxxxxxxxxxxxxxxx>
  • From: George Shuklin <george.shuklin@xxxxxxxxx>
  • Date: Fri, 17 Sep 2010 15:38:44 +0400
  • Delivery-date: Fri, 17 Sep 2010 04:39:19 -0700
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:from:to:in-reply-to:references:content-type:date:message-id :mime-version:x-mailer:content-transfer-encoding; b=ptr1CgwuIauOCOu0mGVbnKkr++GI3HapICzIoqUFdvV5JpRE+S7tZp1SKhtWOmTRFh pfQaPrA0iNT3oY/eSh9c5hbwI9jMV7IeUCdU3fl2rQoopHWUVTcyPB5Atezp8k6XnAmQ caDzJsKKZR6CEuOmErxjnjkty0WsPMmHhG56U=
  • List-id: Discussion of API issues surrounding Xen <xen-api.lists.xensource.com>

Ð ÐÑÐ, 17/09/2010 Ð 09:19 +0100, Jonathan Knowles ÐÐÑÐÑ:
> However one thing not obvious from the FAQ is that the memory
> ballooning daemon is a replaceable component, built separately
> from Xapi, and running as a separate service on each XCP host.
> 
I'm sorry, I think this point is wrong.

Balloon is not a server/dom0 component, it is a kernel module for domU
kernel. It reads from XenStore variables:

static-max = "4194304"
target = "1048576"
dynamic-min = "1048576"
dynamic-max = "1048576"

(numbers copied from random VM)

and acts as variable 'target' prescript.

So when someone set xe vm-memory-target-set (or dynamic) it simply order
to xapi master to order xapi slaves change those values and balloon
driver in domU will do all work.

(So, if you are using non-cooperative system, no memory ballancing at
all).

> > This is reason I always set dynamic-min==dynamic-max - to
> > DISABLE this cruel DMC.
> 
> I agree that DMC could be cruel. After all, if we're going to
> be philosophical about this, then it's just a piece of software
> without a mind :). Having said that, I think its effectiveness
> really depends on how you set it up and in what scenario you're
> using it.

I'd like to announce our own system named MOD (Memory on Demand) wich
one use xenballoon for graceful memory allocating to guest machines.

Right now it under research and testing, but it looks really good: it
never steal memory to cause oom killer doing it dirty job.

Main idea: we looking to memory data, calculating free memory and
setting target for xenballoon to preserve some amount of free memory (We
use static-min static-max values as borders for allowed changes).

Right now we using strightforward algorithm 'preserve X MiB of free
memory', in future I think we can switch to some more intellectual
algorithm with prediction system.


... And I looking to memory-hotplug support in xenballoon in Xen 4. I
test it, and it was amazing: I raise memory from 48MiB to 40GiB of free
memory in few seconds without overhead.


... And one very important thing about xenballon: It take some memory to
operate (in case of -xen kernel and very high 'memory-static-max' value
it can eat few MiBs). Main trouble different -xen kernels displays in
different forms: some displays them as free, but do not allowing to use
it.


_______________________________________________
xen-api mailing list
xen-api@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/mailman/listinfo/xen-api


 


Rackspace

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