Re: RFC: Still TODO for 4.2? xl domain numa memory allocation vs xm/xend

[Dario Faggioli <dario.faggioli@citrix.com>]

[-- Attachment #1.1: Type: text/plain, Size: 2618 bytes --]

On Fri, 2012-01-20 at 11:22 +0000, Ian Campbell wrote: 
> > It seems that xend is retrieving numa info about the platform, see
> > pyxc_numainfo, then using those info to pin vcpus to pcpus, see
> > _setCPUAffinity.
> > Still it seems to me more of an hack than the right way to solve the
> > problem.
> 
> Right, so in the absence of any explicit configuration it basically
> picks a NUMA node (via some heuristic) and automatically puts the guest
> into it.
> 
Seems so. As Stefano is saying I don't think this is something that
should be done at the toolstack level, or at least not at the xl-level
of the toolstack. :-)

> It seems to me that xl's behaviour isn't wrong as such, it's just
> different.
> 
Indeed.

> I think the important thing is that xl should honour user's explicit
> requests to use a particular node, either via vcpu pinning or cpupools
> etc.
> 
And I agree again, honouring explicit user requests is key point. I
think the issue here is what should be dona, say by default, i.e., if
the user doesn't say anything about CPU/memory allocation. My idea was
to have Xen supporting a "NUMA-aware operational mode" where (and this
will actually be the first step!) it does exactly what xend is doing
right now --- that is, choosing a node and putting the new guest there,
both memory and CPU-wise. However, having this logic in the hypervisor
would allow Xen itself, for example, while investigating which node to
use for a new guest, or during a sort of periodic load balancing or
whatever, to change its mind and move a guest to a different node from
where it was put in the first place, as well as a bunch of other things.
I'm not sure the same can be done within the toolstack but I think I can
say that if it can, it would be way more complex and probably less
effective... Am I wrong?

Of course, even in such mode, if the user explicitly tells us what he
wants, e.g., by means of cpupools, pinning, etc., we should still honour
such request.

Then the question is whether or nod this mode would be the default, or
would need to be explicitly requested (boot parameter or something), but
that would become important only when we will have it up and
running... :-)

What do you think? Does this look reasonable? As the topic has been
raised, I'd very much enjoy some early feedback! :-P

Regards,
Dario

-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
-------------------------------------------------------------------
Dario Faggioli, PhD, Senior Software Engineer, Citrix Systems R&D Ltd.,
Cambridge (UK)



[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel