From mboxrd@z Thu Jan  1 00:00:00 1970
From: Dario Faggioli <raistlin@linux.it>
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:47:56 +0200
Message-ID: <1342604876.19530.124.camel@Solace>
References: <patchbomb.1341932613@Solace>
	<0411b2cebd725b193465.1341932614@Solace>
	<20485.35590.105351.434937@mariner.uk.xensource.com>
	<patchbomb.1342458791@Solace> <5fa66c8b9093399e5bc3.1342458792@Solace>
	<20485.43293.833036.352186@mariner.uk.xensource.com>
	<1342570947.11794.92.camel@Abyss>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="===============8412094850843944618=="
Return-path: <xen-devel-bounces@lists.xen.org>
In-Reply-To: <1342570947.11794.92.camel@Abyss>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: Andre Przywara <andre.przywara@amd.com>, Ian Campbell <Ian.Campbell@citrix.com>, Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>, George Dunlap <George.Dunlap@eu.citrix.com>, Juergen Gross <juergen.gross@ts.fujitsu.com>, xen-devel <xen-devel@lists.xen.org>
List-Id: xen-devel@lists.xenproject.org


--===============8412094850843944618==
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature";
	boundary="=-P55jgm7ac53gSRxeWh3f"


--=-P55jgm7ac53gSRxeWh3f
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, 2012-07-18 at 02:22 +0200, Dario Faggioli wrote:
> Moreover, as another input parameter is a nodemask, telling the
> algorithm not only how many but also _which_ nodes it should consider,
> one could imagine to have some multi-tier form of the algorithm itself,
> or, perhaps, implementing a more abstract and coarse partitioning
> heuristics among group of nodes (which will better be done as soon as
> we'll see how 32 and 64 nodes system will actually look like :-D) and
> then run the current algorithm only on these groups, with numbers that
> would then look just like above.
>=20
Alternatively (or maybe not even that much 'alternatively' :-)), we can
try turning it into something a bit more greedy, e.g., searching for
available placement solutions just as big as min_nodes says (typically
1) as a first step (complexity linear with the number of nodes).

After that, if we did not find anything, we could have some sort of
config switch telling us if we should continue, and maybe investigating
candidates of sizes in the range [min_nodes+1,LIBXL__MAX_GUEST_NODES].=20

At which point, if we haven't found anything yet, we could just give up
or, perhaps, think and implement in the near future a more coarse and
less precise mechanism for proceeding further.

Implementing something like that on top of what I have now (which I'll
resend asap, as soon as I've addressed the minor comments I got) during
4.3 should be pretty easy. Also, if we decide to just statically limit
max_nodes<=3DLIBXL__MAX_GUEST_NODES (or whatever we could call it) to
something (I was proposing 4 in the other e-mail) for 4.2, backporting
to it will be piece of cake as well. :-)

Thanks again and Regards,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)



--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


--=-P55jgm7ac53gSRxeWh3f
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)

iEYEABECAAYFAlAGhkwACgkQk4XaBE3IOsSGrwCfatQOp5WFh6mAG4t7V920d+js
me0AnibCo/cj8PWA2/CLVNSI1FOcZS9k
=u72j
-----END PGP SIGNATURE-----

--=-P55jgm7ac53gSRxeWh3f--



--===============8412094850843944618==
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

--===============8412094850843944618==--