From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli Subject: Re: [PATCH 09 of 10 [RFC]] xl: Introduce Best and Worst Fit guest placement algorithms Date: Mon, 16 Apr 2012 11:29:34 +0100 Message-ID: <1334572174.2417.17.camel@Abyss> References: <62ef1186c24b850cbc1c.1334150276@Solace> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2962668513317338837==" Return-path: In-Reply-To: <62ef1186c24b850cbc1c.1334150276@Solace> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: xen-devel@lists.xen.org Cc: Andre Przywara , Ian Campbell , Stefano Stabellini , George Dunlap , Juergen Gross , Ian Jackson , Jan Beulich List-Id: xen-devel@lists.xenproject.org --===============2962668513317338837== Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-8WMcL80bYZ3q3z2lDD7c" --=-8WMcL80bYZ3q3z2lDD7c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, 2012-04-11 at 15:17 +0200, Dario Faggioli wrote:=20 > Besides than "auto" and "ffit", as per the previous patch, enable > Best and Worst Fit placement heuristics to `xl`, for the user to > chose them in the config file. Implementation just sits on top > of the First Fit algorithm code, with just the proper reordering > of the nodes and their free memory before invoking it (and after > it finishes). >=20 > TODO: * As usual for this series, benchmarking and testing, > as much thorough and comprehensive as possible! >=20 I manage in getting some numbers from these placement heuristics too. http://xenbits.xen.org/people/dariof/benchmarks/specjbb2005-numa_aggr/index= .html As a foreword, they come from some of the benchmarks I already run, and from running some new ones, but with the same logic and infrastructure, meaning: - all the VMs were equal in (memory) size - all the VMs had the same # of VCPUs - all the VMs are always created in the very same order These are definitely not the best condition for stressing the algorithms, neither they are for trying to understand the algorithms' differences and capabilities of bringing performance benefits... Anyway, they're _something_, and a slight improvement wrt default placement is already noticeable in the graphs. :-) Look, for example, at one here this: http://xenbits.xen.org/people/dariof/benchmarks/specjbb2005-numa_aggr/2.htm= l And compare the red curve (default placement/schedulig) with all the other ones. They all represents the aggregate throughput achieved by the SpecJBB 2005 benchmark --counting (and averaging it on) all the VMs-- when varying the number of VMs, so as usual for SpecJBB, higher is better. "wfit" and "bfit" clearly works better than "default", which would have been desirable, and actually expected, especially for Worst Fit, in this particular scenario. It is also normal that "ffit" does a worse job than "default" until the number of VMs excedes 4. In fact, considering the amount of RAM each VM has (without forgetting some RAM is assigned to Dom0 as well), with less than 5 VMs all of them are fitted on the first NUMA node, thus the memory accesses are local, but the load distribution is clearly sub-optimal! As for the scheduling related results, more serious testing and tracing is needed in order to verify things are happening as expected, but the graphs seemed nice to me, and I thus thought it could be worth sending them, while working on having more interesting ones. :-) 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) --=-8WMcL80bYZ3q3z2lDD7c 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) iEYEABECAAYFAk+L9I8ACgkQk4XaBE3IOsR0+gCfWesLK7O10AhHQHTBdUaOcbsj 1NEAn0SrubK9MOXk2iLOUPIVjF3gxFft =DTnA -----END PGP SIGNATURE----- --=-8WMcL80bYZ3q3z2lDD7c-- --===============2962668513317338837== 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 --===============2962668513317338837==--