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: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Subject: Re: [Xen-devel] [PATCH 2 of 8] libxl: introduce libxl_set_relative_memory_target
From: Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>
Date: Thu, 2 Sep 2010 10:15:24 +0100
Cc: Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>, Stefano Stabellini <Stefano.Stabellini@xxxxxxxxxxxxx>
Delivery-date: Thu, 02 Sep 2010 02:16:29 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4C7E94F0.5050802@xxxxxxxx>
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> <4C7E94F0.5050802@xxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Alpine 2.00 (DEB 1167 2008-08-23)
On Wed, 1 Sep 2010, Jeremy Fitzhardinge wrote:
> 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.

I actually agree with you on this point, but yesterday morning I
couldn't come up with any practical use case to support this argument.

> 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
>     target_memkb)
> (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
>     target_memkb)
> 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).

Considering that there is already a libxl function to set memmax
(libxl_domain_setmaxmem), I'll just keep libxl_set_memory_target as it
is because it might be very useful to set a new target and a new memmax
in a single transaction.

Xen-devel mailing list