From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dan Magenheimer Subject: Re: NUMA TODO-list for xen-devel Date: Fri, 3 Aug 2012 15:34:53 -0700 (PDT) Message-ID: <6843caa4-9ef7-4e9d-97e5-9ebee55ec6e4@default> References: <1343837796.4958.32.camel@Solace> <501A67C502000078000921FF@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <501A67C502000078000921FF@nat28.tlf.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich , Dario Faggioli Cc: Andre Przywara , Anil Madhavapeddy , George Dunlap , xen-devel , Andrew Cooper , Yang Z Zhang List-Id: xen-devel@lists.xenproject.org > From: Jan Beulich [mailto:JBeulich@suse.com] > 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 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.