From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli Subject: Re: RFC: Still TODO for 4.2? xl domain numa memory allocation vs xm/xend Date: Mon, 23 Jan 2012 14:14:15 +0100 Message-ID: <1327324455.2476.4.camel@Abyss> References: <1325694562.25206.304.camel@zakaz.uk.xensource.com> <20120119211430.GT12984@reaktio.net> <1327046368.21391.29.camel@dagon.hellion.org.uk> <1327058562.17599.134.camel@zakaz.uk.xensource.com> <1327059874.2337.38.camel@Abyss> <1327060480.30054.15.camel@zakaz.uk.xensource.com> <1327061083.2337.42.camel@Abyss> <1327062788.30054.31.camel@zakaz.uk.xensource.com> <1327065091.30054.43.camel@zakaz.uk.xensource.com> <1327071976.30054.55.camel@zakaz.uk.xensource.com> <1327075340.2337.50.camel@Abyss> <1327076495.30054.63.camel@zakaz.uk.xensource.com> <1327076924.30054.65.camel@zakaz.uk.xensource.com> <1327077068.23358.97.camel@elijah> <1327077590.30054.71.camel@zakaz.uk.xensource.com> <1327077796.23358.98.camel@elijah> <1327078460.30054.74.camel@zakaz.uk.xensource.com> <1327080768.2337.65.camel@Abyss> <1327313995.24561.13.camel@zakaz.uk.xensource.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============9089661589145720289==" Return-path: In-Reply-To: <1327313995.24561.13.camel@zakaz.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Ian Campbell Cc: xen-devel , "Keir (Xen.org)" , Stefano Stabellini , George Dunlap , "Tim (Xen.org)" , Juergen Gross , Ian Jackson , Jan Beulich List-Id: xen-devel@lists.xenproject.org --===============9089661589145720289== Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-U3pxmLH2fvW++9EIS874" --=-U3pxmLH2fvW++9EIS874 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, 2012-01-23 at 10:19 +0000, Ian Campbell wrote:=20 > > According to me, it should. >=20 > I agree. >=20 > One idea I had over the weekend is that we could support a special > 'cpus=3D"pool"' syntax to mean "pin this guest to the node I configured i= t > to be in". I think this is a second best option to simply having > d->node_affinity reflect the pool though. >=20 Which is exactly what Juergen is doing, right? Or you meant something else? > > Then, at least right now, moving it would > > probably kill its performances because all its memory will be far away, > > while right now it's all more "stochastic". >=20 > Yes, in some sense the xend behaviour is best case good behaviour and > worse case bad behaviour, while xl has a more average/consistent > behaviour across the range. In practice however I suspect xend probably > hits the good cases more often than not. >=20 Me too. I'm thinking how/working to get to something even better! :-) Regards, Dario --=20 <> (Raistlin Majere) ------------------------------------------------------------------- Dario Faggioli, http://retis.sssup.it/people/faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) PhD Candidate, ReTiS Lab, Scuola Superiore Sant'Anna, Pisa (Italy) --=-U3pxmLH2fvW++9EIS874 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.11 (GNU/Linux) iEYEABECAAYFAk8dXScACgkQk4XaBE3IOsSOzwCfT0BnOaAmv49woxGTunDNA1qg 0iAAoKye9x/fJbYeaO208UIvISRZuQC5 =jU1W -----END PGP SIGNATURE----- --=-U3pxmLH2fvW++9EIS874-- --===============9089661589145720289== 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.xensource.com http://lists.xensource.com/xen-devel --===============9089661589145720289==--