From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli 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 Message-ID: <1342620013.11794.107.camel@Abyss> References: <0411b2cebd725b193465.1341932614@Solace> <20485.35590.105351.434937@mariner.uk.xensource.com> <5fa66c8b9093399e5bc3.1342458792@Solace> <20485.43293.833036.352186@mariner.uk.xensource.com> <1342570947.11794.92.camel@Abyss> <1342602839.26734.6.camel@zakaz.uk.xensource.com> <1342604616.19530.123.camel@Solace> <1342605184.26734.19.camel@zakaz.uk.xensource.com> <20486.38718.474388.724787@mariner.uk.xensource.com> <5006BCC1.7050001@amd.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2136202623276332819==" Return-path: In-Reply-To: <5006BCC1.7050001@amd.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: Andre Przywara Cc: Ian Campbell , Stefano Stabellini , George Dunlap , Juergen Gross , Ian Jackson , xen-devel List-Id: xen-devel@lists.xenproject.org --===============2136202623276332819== Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-TEPCZntYxU80wTfvGEvd" --=-TEPCZntYxU80wTfvGEvd Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Andre, On Wed, 2012-07-18 at 15:40 +0200, Andre Przywara wrote:=20 > > 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. >=20 > 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.=20 > This has ever been the case since the release of Opteron and changing=20 > this is not trivial and will not happen in any near future. > Cool, thanks for bringing your view into this discussion! :-) > In general I=20 > don't think we will see much bigger NUMA systems, but more cluster like= =20 > architectures. >=20 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. >=20 That would be very interesting. > So my suggestion: Get this NUMA placement in if anyhow possible for=20 > 4.2.0. We have much bigger problems without this algorithm than the=20 > theoretic gigantic machine you are talking about. Since it is an=20 > internal algorithm, we can fix this later easily in 4.2.1 and 4.3 and=20 > nobody will ever notice this problem. >=20 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 --=20 <> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) --=-TEPCZntYxU80wTfvGEvd Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEABECAAYFAlAGwW0ACgkQk4XaBE3IOsTeCwCfUspPBZO1MHu4P35s+bbaFO9s mQgAniB+v7LiNBcGN0Nb6FF8Jfcv8Bf8 =BwdB -----END PGP SIGNATURE----- --=-TEPCZntYxU80wTfvGEvd-- --===============2136202623276332819== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============2136202623276332819==--