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

[George Dunlap <George.Dunlap@xxxxxxxxxxxxx>]

On Thu, Aug 2, 2012 at 2:34 PM, 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?
>
> 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?)

I think we could use cpu hot-plug to change the "virtual topology" of
VMs, couldn't we?  We could probably even do that on a running guest
if we really needed to.

 -George

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