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

Re: [Xen-devel] memory hotplug for domUs



Juergen Gross writes ("Re: [Xen-devel] memory hotplug for domUs"):
> While the syntax for "xl mem-add" (or however we would call it) could
> be rather clear and simple:
> 
> xl mem-add <domain> <mem-amount> [--host-node <xy>] [--guest-node <ab>]
> 
> I don't see how this would be the case for xl mem-set. Imagine a guest
> ballooned down and now you are setting a memory size above its current
> maxmem value. What should be done? Should the guest first be ballooned
> up and then a hotplug operation is to happen? Or should all the memory
> missing be added via hotplug? Should xl mem-set with numa nodes
> specified be rejected in case the requested size could be achieved by
> ballooning up?
> 
> In case of removing memory: should ballooning or hotplug or a
> combination of both be used?
> 
> With xl mem-add/mem-remove this would be very clear. We could even
> support adding pre-ballooned memory (might be interesting in case a
> guest supports only hotplugging of specific memory sizes but one
> wants to add less host memory to the guest).

The problem I have with this approach is that from most users' point
of view, static-max is not a very meaningful concept.  If the user has
to `mem-add' iff the new amount is bigger than the static-max, this
makes the whole thing very odd to use.

I do see that these numa node allocation possibilities make matters
more complicated, but the usual case is that the user will want the
default numa allocation strategy; and the next usual case is that they
specified an allocation strategy at domain creation time, in the
domain config file.  I don't think the dynamic numa special cases
should be allowed to force us into making an interface which is
unnatural in the usual cases.

Bottom line: I want `xl mem-set', without further options, when
supported by the guest, to automatically do any memory hotplug that
may be required, according to the domain's existing numa allocation
policy (whatever that may be).

For users who want to adjust the numa allocation strategy during the
life of the domain, I am content that there should be more complex
mechanisms.  So I don't think we need numa options to mem-set unless
that is the most convenient interface.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel

 


Rackspace

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