From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli Subject: Re: [PATCH 1 of 3] libxl: take node distances into account during NUMA placement Date: Fri, 19 Oct 2012 12:56:08 +0200 Message-ID: <1350644168.6053.15.camel@Solace> References: <1350602433.26152.106.camel@Solace> <20609.9598.286219.485359@mariner.uk.xensource.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8168972353356251796==" Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Stefano Stabellini Cc: Andre Przywara , Ian Campbell , George Dunlap , Juergen Gross , Ian Jackson , "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org --===============8168972353356251796== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-U+ShO+wra6Cot9Xg8jqD" --=-U+ShO+wra6Cot9Xg8jqD Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, 2012-10-19 at 11:39 +0100, Stefano Stabellini wrote: > On Fri, 19 Oct 2012, Ian Jackson wrote: > > Dario Faggioli writes ("Re: [Xen-devel] [PATCH 1 of 3] libxl: take node= distances into account during NUMA placement"): > > > It is, with N being the number of nodes, which we discussed thoroughl= y > > > already a couple of months ago, and reached consensus on the fact tha= t N > > > will stay less than 8 for the next 5 (but probably even more) years. = :-) > >=20 > > No, I don't think we did reach consensus about that. It was asserted > > but I dissented. I don't think this is a reasonable assumption. >=20 > When Dario speaks about consensus in terms of hardware that is going to > reach the market, he really means what Intel and AMD have told us. >=20 Indeed. That being said, I really wanted to avoid re-starting that discussion so, while trying to summarize it as quickly as possible, I've no problem admitting that "reach consensus" could not be the perfect choice of words. My bad. The whole point is that the solution we have (and that I'm trying to keep up improving with these patches) is both viable with current and near future hardware and no harms with any crazy unexpectable breakthrough in CPU design --thanks to the safety catch IanJ suggested.=20 Moreover, it is easily amendable, for example taking more advantage of cpupools (with witch the placement algorithm is already integrated up to some extent), in case the latter happens. This is so true that, as I already said, I've no problem even starting to think about how to put it together. Maybe not from tomorrow (I'm quite busy with other stuff :-D), but definitely before 4.3, if we think it's something we couldn't live without. > Sorry but your opinion doesn't count that much in the matter of cpu > architecture being produces in the near future, unless you have already > started a secret Californian cpu startup, that nobody knows about yet > ;-) > :-D 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) --=-U+ShO+wra6Cot9Xg8jqD 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) iEYEABECAAYFAlCBMcgACgkQk4XaBE3IOsS7cwCfTXPRjcQ0PevaLVUS5CbGZ5tw 7XQAn1pClT8F9Y6VN1yUaRyNoAT04fWC =a2vp -----END PGP SIGNATURE----- --=-U+ShO+wra6Cot9Xg8jqD-- --===============8168972353356251796== 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 --===============8168972353356251796==--