Re: [Xen-devel] NUMA TODO-list for xen-devel

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 02.08.12 at 15:34, Dario Faggioli <raistlin@xxxxxxxx> wrote:
> On Thu, 2012-08-02 at 10:43 +0100, Jan Beulich wrote:
>> >>> On 01.08.12 at 18:16, Dario Faggioli <raistlin@xxxxxxxx> 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?

Yes.

> 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

Indeed.

>> >        * 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.

We certainly can't, the more that the "big enough" case may not
be that infrequent going forward.

Jan


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