Re: NUMA TODO-list for xen-devel

[Dario Faggioli <raistlin@linux.it>]

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

On Thu, 2012-08-02 at 10:43 +0100, Jan Beulich wrote:
> >>> On 01.08.12 at 18:16, Dario Faggioli <raistlin@linux.it> wrote:
> >     - Virtual NUMA topology exposure to guests (a.k.a guest-numa). If a
> >       guest ends up on more than one nodes, make sure it knows it's
> >       running on a NUMA platform (smaller than the actual host, but
> >       still NUMA). This interacts with some of the above points:
> 
> The question is whether this is really useful beyond the (I would
> suppose) relatively small set of cases where migration isn't
> needed.
> 
Mmm... Not sure I'm getting what you're saying here, sorry. Are you
suggesting that exposing a virtual topology is not a good idea as it
poses constraints/prevents live migration?

If yes, well, I mostly agree that this is an huge issue, and that's why
I think wee need some bright idea on how to deal with it. I mean, it's
easy to make it optional and let it automatically disable migration,
giving users the choice what they prefer, but I think this is more
dodging the problem than dealing with it! :-P

> >        * consider this during automatic placement for
> >          resuming/migrating domains (if they have a virtual topology,
> >          better not to change it);
> >        * consider this during memory migration (it can change the
> >          actual topology, should we update it on-line or disable memory
> >          migration?)
> 
> The question is whether trading functionality for performance
> is an acceptable choice.
> 
Indeed. Again, I think it is possible to implement things flexibly
enough, but then we need to come out with a sane default, so we're not
allowed to avoid discussing and deciding on this.

One can argue that it is an issue only for big-enough guests (and/or
nearly overcommitted hosts) that don't fit in only one node (as, if they
do, there is no virtual topology to export), but I'm not sure we can
neglect them on this basis.

Thanks for the feedback,
Dario

-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
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: 126 bytes --]

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