From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli Subject: Re: [PATCH 2 of 4 v7/leftover] libxl: enable automatic placement of guests on NUMA nodes Date: Thu, 26 Jul 2012 15:54:38 +0200 Message-ID: <1343310878.6187.45.camel@Solace> References: <6dab5496964de0830f1a.1343140929@Solace> <5011321F.6080601@amd.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6600115308235457677==" Return-path: In-Reply-To: <5011321F.6080601@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 , Roger Pau Monne List-Id: xen-devel@lists.xenproject.org --===============6600115308235457677== Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-XvccmwAgmVYIM7/Qt6e9" --=-XvccmwAgmVYIM7/Qt6e9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, 2012-07-26 at 14:03 +0200, Andre Przywara wrote: > I have tested this version 7 on my box in various configurations: > 1. Homogeneous memory distribution: 8 nodes, each 16 GB > 2. "Odd" configuration: 8 nodes, 4 have 8 GB, 4 have 16 GB > 3 Flat memory (by using cpus=3D"all") >=20 > I created up to 32 guests with 2 VCPUs and 2 GB each and observed the=20 > distribution after every 8th guest. > Another round with 2 VCPU guests, but this time with memory sizes=20 > varying from 512MB to 5120MB. >=20 Wow, that sounds like a lot of work... Thanks a ton for doing this Andre! :-) > The placement was running well in all cases. > It's hard to describe how much I am pleased to hear this. :-P > The only thing I saw as a little sub-optimal placement in the odd=20 > configuration (2) with the differently sized guests. This is probably a= =20 > side effect of Dom0 ballooning, which is not really NUMA aware AFAIK.=20 > This leads to a situation, where some nodes just by chance have less=20 > memory than a certain guest needs and so are not considered candidates. > Yes, that sounds a more than possible explanation. Honestly, I think that no matter how good we are in finding algorithms and heuristics, there always will be some weird combination of host and guest configurations that will lead to equally weird results. That being said, I also think the algorithm's structure is flexible enough to allow us trying to do better in at least some of this weird but possible situation. For example, we surely can play with some of the parameters we pass to libxl__get_numa_candidate() and with the comparison function in order to deal better with asymmetrical hosts... In the near _future_ !!=20 Also, instilling some NUMA-awareness in other components, such as the ballooning machinery, should be on our todo-list, for 4.3 perhaps. > So this patch gets my: >=20 > Tested-by: Andre Przywara >=20 That's the important thing for now. :-) Thanks again 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) --=-XvccmwAgmVYIM7/Qt6e9 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) iEYEABECAAYFAlARTB4ACgkQk4XaBE3IOsRAFgCgjEd1gEpfO4JLWA6B0n6Hau0m JAAAn1H5J9slGybEot1e55rGwFQ0/uSN =rBKI -----END PGP SIGNATURE----- --=-XvccmwAgmVYIM7/Qt6e9-- --===============6600115308235457677== 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 --===============6600115308235457677==--