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] [PATCH 2 of 8] libxl: introduce libxl_set_relative_memor

To: Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH 2 of 8] libxl: introduce libxl_set_relative_memory_target
From: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Date: Wed, 01 Sep 2010 11:01:20 -0700
Cc: Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx, Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>
Delivery-date: Wed, 01 Sep 2010 11:02:05 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <19581.15132.637644.952724@xxxxxxxxxxxxxxxxxxxxxxxx>
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: <alpine.DEB.2.00.1008271215210.2545@kaball-desktop> <19581.15132.637644.952724@xxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20100806 Fedora/3.1.2-1.fc13 Lightning/1.0b2pre Thunderbird/3.1.2
 On 08/31/2010 10:25 AM, Ian Jackson wrote:
> Stefano Stabellini writes ("[Xen-devel] [PATCH 2 of 8] libxl: introduce 
> libxl_set_relative_memory_target"):
>> libxl: introduce libxl_set_relative_memory_target
>> Introduce libxl_set_relative_memory_target to modify the memory target
>> of a domain by a relative amount of memory in a single xenstore
>> transaction.
>> Modify libxl_set_memory_target to use xenstore transactions.
>> The first time we are reading/writing dom0 memory target, fill the
>> informations in xenstore if they are missing.
>>  int libxl_set_memory_target(libxl_ctx *ctx, uint32_t domid,
>>                              uint32_t target_memkb, int enforce)
> See my earlier comments about memory targets.  I don't think it makes
> much sense to give a domain a memory target and then let it exceed it.
> So I think "enforce" should be abolished (as if it were always set).

There needs to be a way to set the maxmem for a domain without also
setting the memory/target xenstore key, so that you can allow a domain
to control its own ballooning up to a certain limit without also
triggering its xenstore watch (which would trigger an external balloon
target request).

Ideally there should also be a xenstore key that allows a guest to
determine what its max is, rather than just feeling for it until it gets
hypercall failures.

In general, guests can treat "memory/target" as a host recommendation of
what size it should ideally be if it is being as cooperative as
possible.  A simple implementation - like the current balloon driver -
just treats it literally.  But there's no reason why that's the best
thing to do.  (If there is some kind of cost model where there's an
active incentive for a domain to reduce its own memory usage it would
change the landscape a lot.)

By extension, there's no reason why the guest must be limited by
"target" - its possible that its ideal size, based on its own internal
memory pressure - is larger than target.  It can stay larger than target
if it is shrinking by stopping before it hits target, but I don't see an
inherent reason why the toolstack might not want to suggest a particular
target but allow a domain to grow beyond that.

There's also the question of how tmem makes use of maxmem - I believe it
allows a domain to use tmem pages up to its maxmem, without actually
changing the current memory usage in terms of pages mapped into the domain.

If libxl is supposed to be the general-purpose base of a toolstack, I
don't think it should be trying to make these kinds of policy decisions
("target == max") internally - or implicitly as part of the API design.

In this case, I think it would be most sensible to have:

    int libxl_set_memory_target(libxl_ctx *ctx, uint32_t domid, uint32_t

(no enforce parameter) which simply sets the target xenstore key
(nothing else), and

    int libxl_set_memory_limit(libxl_ctx *ctx, uint32_t domid, uint32_t

which sets the domain's Xen-enforced max size (and maybe a xenstore key
so that the domain can tell that its max has been changed and what to).

And that's it.  The target and limit are completely orthogonal concepts,
and there definitely should not be any implementation of rules like
"target must be smaller than limit".

If a toolstack wants to implement more mechanism/policy on top of this,
it is free to do so.  But libxl should just provide plain basics.


Xen-devel mailing list