Re: [PATCH 1 of 3 v5/leftover] libxl: enable automatic placement of guests on NUMA nodes [and 1 more messages]

From: Dario Faggioli <raistlin@linux.it>
To: Andre Przywara <andre.przywara@amd.com>
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [PATCH 1 of 3 v5/leftover] libxl: enable automatic placement of guests on NUMA nodes [and 1 more messages]
Date: Wed, 18 Jul 2012 16:00:13 +0200	[thread overview]
Message-ID: <1342620013.11794.107.camel@Abyss> (raw)
In-Reply-To: <5006BCC1.7050001@amd.com>

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

Hi Andre,

On Wed, 2012-07-18 at 15:40 +0200, Andre Przywara wrote: 
> > What is the maximum number of NUMA nodes we might expect to see on a
> > single system in the next five years?  I would argue that 32 is too
> > optimistic.  128 or 256 seem like more reasonable upper bounds.
> 
> Wow, what are you talking about?
> To calm this down from the AMD side:
> The current Opteron NUMA architecture is limited to exactly 8 nodes. 
> This has ever been the case since the release of Opteron and changing 
> this is not trivial and will not happen in any near future.
>
Cool, thanks for bringing your view into this discussion! :-)

> In general I 
> don't think we will see much bigger NUMA systems, but more cluster like 
> architectures.
> 
Yep, I think that too, but hearing this from you is much more important
than hearing it from me as, given your position, your crystal ball is
quite a bit more trained for this kind of foresight than our ones! :-P

> Maybe Juergen can comment on the Fujitsu side.
> 
That would be very interesting.

> So my suggestion: Get this NUMA placement in if anyhow possible for 
> 4.2.0. We have much bigger problems without this algorithm than the 
> theoretic gigantic machine you are talking about. Since it is an 
> internal algorithm, we can fix this later easily in 4.2.1 and 4.3 and 
> nobody will ever notice this problem.
> 
While I basically agree, I think the solution would benefit from some
kind of "safety stop condition" similar to the one IanJ suggested. I'm
just trying to fine tune it a bit, to be sure as much as possible system
might benefit from the placement.

Thanks and Regards,
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