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

[Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>]

> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
> Sent: Thursday, August 02, 2012 3:43 AM
> To: Dario Faggioli
> Cc: Andre Przywara; Anil Madhavapeddy; George Dunlap; xen-devel; Andrew 
> Cooper; Yang Z Zhang
> Subject: Re: [Xen-devel] NUMA TODO-list for xen-devel
> 
> >>> 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.
> 
> >        * 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.

If there were a lwn.net equivalent for Xen, I'd be pushing to get
quoted on the following:

"Virtualization: You can have flexibility or you can have performance.
Pick one."

A couple of years ago when NUMA was first being extensively discussed
for Xen, I suggested that this should really be a "top level" flag
that a sysadmin should be able to select: Either optimize for
performance or optimize for flexibility.  Then Xen and the Xen tools
should "do the right thing" depending on the selection.

I still think this is a good way to surface the tradeoffs for
a very complex problem to the vast majority of users/admins.
Clearly they will want "both" but forcing the choice will
provoke more thought about their use model, as well as provide
important guidance to the underlying implementations.


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