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
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).
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.
J
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home