Re: [Xen-devel] [PATCH 2 of 8] libxl: introduce libxl_set_relative_memory_target

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

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
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel