From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli Subject: Re: Can't always start 32 bit domains after 64 bit domains Date: Sun, 27 Nov 2016 02:14:11 +0100 Message-ID: <1480209251.2712.252.camel@citrix.com> References: <3423fa13-18bd-ff7b-f44a-af015eda2eb7@prgmr.com> <5832BC4F0200007800120396@prv-mh.provo.novell.com> <5832D50602000078001203F7@prv-mh.provo.novell.com> <1479840405.2712.36.camel@citrix.com> <6a400e0e-9150-5652-706d-95dc4b660f8d@prgmr.com> <1479850819.2712.53.camel@citrix.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7610850993956118746==" Return-path: In-Reply-To: <1479850819.2712.53.camel@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xen.org Sender: "Xen-devel" To: Sarah Newman , Andrew Cooper , Jan Beulich , LarsKurth Cc: xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org --===============7610850993956118746== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="=-Q4HfB9QKAqgqghH49N79" --=-Q4HfB9QKAqgqghH49N79 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, 2016-11-22 at 22:40 +0100, Dario Faggioli wrote: > On Tue, 2016-11-22 at 11:37 -0800, Sarah Newman wrote: > > If you're saying not specifying "cpus=3D..." will keep libxl from > > interfering with the Xens default allocation policy, then Xens > > default allocation > > policy no longer starts from the top of memory for 64 bit PV > > domains, > > at least for 4.6.3. Maybe it's starting from the top of memory per > > node. > >=20 > No, I'm saying that _not_ specifying cpus=3D will trigger libxl > interference. _Do_ specifying it, will either limit or disable it, > depending on how you specify it. >=20 > That's all I'm saying. >=20 And let me just add that, the automatic NUMA placement algorithm is very flexible and extendible. As I said, I didn't pay much attention at this 32 bit guests memory issue when doing it (neither did anyone reviewing the code), and I'm sorry if this is causing troubles. But, really, if we want to feed a constraint, or a preference about this inside the algorithm, we can do that without much hassle, and I'm happy to help with that. For instance (and I'm really just thinking out loud here), let's assume that we know memory on NUMA node 0 is what 32 bit guests need: we can instruct the placement algorithm to either disfavour or ignore node 1 when placing a 64 bit guest. Or something like that... If you think this could be interesting, let's talk about it. As soon as I'll fully understand the constraint, and we'll have agreed on an interface (e.g., a xl.conf flag?) and on the best course of action (e.g., disfavour vs. forbid), I can write the code myself. :-) Regards, Dario --=C2=A0 <> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) --=-Q4HfB9QKAqgqghH49N79 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 v2 iQIcBAABCAAGBQJYOjNjAAoJEBZCeImluHPuNlAQAOrScOy9wsRVeFyEDhrS8nsv 8wBE2CbTEkFWifbrVMhmkegU0KANvcMaogA3NKbwkPs7VFpwo58c6mJZHPAOX7Ur Qwz4IVN1i3Sc1QB3oxzhqhAjMEoeLNMzvEHojkC7Ymzguy5ZFLz1wg+W5hHMdwgz J3hV3MfnDjxO/BYueM07jTRnUB23iVjyDPWtisZcVt+dz4UpLiWj6gU5mx5q/WTR f9jdcUK/oce6ygvjU7RTJkT3MhReKctV5x+VWtwsrGzghvm5w4ChrbJNliKL8WZI K8fKwVHwvo/XkUJTvGOXqbAaYGQDvb8VZXF7j8JlBpFx3RdGB18lkWP6202AKs1c SbOQj+EAz7qcxOzl8o9UTWXVsE+tmTP9KlT8hCfVhCkclTuL2R9628Vio2IMsGaG 3bhSKr/XA3W1VaFoBkwD3m2SeXmKBmZGrAj+2ys8ytK/ES5lH6vwGpQuvkDvIwAr r0aOwPbyTdF8BHxY1sZM58JdLjdi9TRlwRLpvZVxBjrlkDVyNikHls6COjPht7r7 RsDqrRXyTV7qW3F3E3OBHn+OYb/zLRTu51wNQ2mlOI9RfaKr+v1gU3GHr7exgu9S E5/XCXFT1k+peroWQ+QJ8NraU1GX4R1WEjJuWkI27aXVwn5k9Bhaqd4oBN798Lm5 /dazc7XDOBchq3AJQ37w =oLCq -----END PGP SIGNATURE----- --=-Q4HfB9QKAqgqghH49N79-- --===============7610850993956118746== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwczovL2xpc3RzLnhlbi5v cmcveGVuLWRldmVsCg== --===============7610850993956118746==--