On 25/01/17 14:02, Dario Faggioli wrote:
> On Tue, 2017-01-24 at 16:03 -0700, Jim Fehlig wrote:
>> On 01/20/2017 09:06 AM, Juergen Gross wrote:
>>> On 20/01/17 16:54, Ian Jackson wrote:
>>>> Juergen Gross writes ("memory hotplug for domUs"):
>>>>> We first thought to enhance "xl mem-set", but after some more
>>>>> thinking
>>>>> about it I'd rather add a new xl command, e.g. "mem-add" (we
>>>>> could later
>>>>> even add "mem-remove" to support memory unplug).
>>>> Why ? Why would xl mem-set not automatically do the right thing
>>>> ?
>>> How would you specify the numa node to add the memory to?
>> And the host numa node providing the memory?
>>
> Exactly!
>
> I've actually always been a lot confused by all these mem-max,
> mem-set, set-mem-max, max-set-mem, static-set-mem-max, set-mem-static-
> max, etc ( :-P ), so I'm not really comfortable giving advices.
>
> However, I strongly agree on the fact that this new capability need to
> be (v)NUMA aware (at least, potentially, for when we'll have complete
> support for that in all the moving parts). Or we risk having to revisit
> and potentially change again and re-document the behavior!
>
> If a new command is not desirable, can't we add options and parameters
> to `xl mem-set', and fallback to some well defined default if they're
> not there ?
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).
>
>>> I think it would be clearer with new commands for hotplugging. I
>>> don't feel very strong about this, so in case everyone else is fine
>>> with handling everything via mem-set I won't object.
>> If ACPI memory hotplug is indeed the goal, then I agree new commands
>> should be
>> used since it is quite different than ballooning.
>>
> Yeah, but again, the multiplexing can also happen inside of xl or
> libxl, basing on parameters, etc.
>
> I think the biggest issue here --as in, the thing we're most in lack of
> right now-- is is to come up with a well defined and well documented
> behavior, much rather than any technical aspect.
Right.
> FWIW, I'm a bit two minded, as I agree with Juergen and Jim that adding
> new commands may be cleaner, but I wonder whether having
> _yet_another_mem_foobar_thing_ would not reveal too confusing and hard
> to use from a user perspective...
I believe trying to do it all via mem-set with magic inside would be
even more confusing. A clear set of commands with each having well
defined semantics is much clearer IMO.
Juergen
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
