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 11:43:36 +0200 Message-ID: <1342604616.19530.123.camel@Solace> 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> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5562909237163313542==" Return-path: In-Reply-To: <1342602839.26734.6.camel@zakaz.uk.xensource.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: Ian Campbell Cc: Andre Przywara , Stefano Stabellini , George Dunlap , Juergen Gross , Ian Jackson , xen-devel List-Id: xen-devel@lists.xenproject.org --===============5562909237163313542== Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-7jAvK9S/vg6F4wMCNGiD" --=-7jAvK9S/vg6F4wMCNGiD Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, 2012-07-18 at 10:13 +0100, Ian Campbell wrote: > On Wed, 2012-07-18 at 01:22 +0100, Dario Faggioli wrote: >=20 > > So, to summarize, I can't be farther than saying the current algorithm > > is perfect or fast. Rather, I'm definitely saying it has the advantage > > of not branching out the problem space too much aggressively at this > > early stage, and it is flexible enough for avoiding getting unreasonabl= e > > performances, or at least, it looks like that to me, I guess. :-) >=20 > I'm not quite following what you are trying to say with all this. >=20 Oh, I see, sorry. :-( > Are you saying that the code as most recently submitted does not have > the O( C(nr_nodes,min_nodes) ) property which Ian J suggests, which > leads to needing to process hundreds of millions of combinations for a > 16 / 32 node guest?=20 > No, I'm not. If you want to place a 16 (32) nodes guest on a 32 (64) nodes host, it is as bad as he says. However, I'm also saying that on <=3D16 nodes host it is able o provide very good placement at a reasonable cost and that, if we limit the number of guest nodes (e.g., up to 4) it is able to do the same even on 32 or 64 nodes hosts. > Or are you saying that it does have this property > but it doesn't matter?=20 > A lot of people is thinking that trying to address the problem of placing guests that are bigger (or anyway, guests that does not fit) in just 1 node should not be even considered. I'm saying that it should and am also proposing an algorithm that is able to provide good placement performances for guests that spans up to 4 nodes even on future 32 or 64 nodes systems. So basically I'm saying that it does have that property but that is bringing benefits right now, and we have all the knobs to limit its potential nasty effects for future (bigger) system at any time. > Or are you saying it does have this property but > you intend to ameliorate it somehow? If the latter then how and for > which release(s) (4.2, 4.3 or 4.2.1)? >=20 Yes, I guess I'm sort of saying something like that. What could be done is restricting automatic placement to guests that fits on 4 or 8 nodes for 4.2. Then, for 4.3 (and with a very small backport effort to 4.2.1), implement a lighter solution for dealing with the ones that does not. Hope I clarified at least a bit. :-) 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) --=-7jAvK9S/vg6F4wMCNGiD 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) iEYEABECAAYFAlAGhUgACgkQk4XaBE3IOsQlvQCgpfnT/5YsVy1BHqzs71JgtPyl xooAn0Q28oV8btvMlXbcfOALGp847qLn =eQIH -----END PGP SIGNATURE----- --=-7jAvK9S/vg6F4wMCNGiD-- --===============5562909237163313542== 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 --===============5562909237163313542==--