From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli Subject: Re: [PATCH RESEND 05/12] xen: numa-sched: make space for per-vcpu node-affinity Date: Wed, 6 Nov 2013 11:00:00 +0100 Message-ID: <1383732000.9207.99.camel@Solace> References: <20131105142844.30446.78671.stgit@Solace> <20131105143500.30446.9976.stgit@Solace> <5279143702000078000FFB15@nat28.tlf.novell.com> <527908B2.5090208@eu.citrix.com> <52790A93.4020903@eu.citrix.com> <52791B8702000078000FFBC4@nat28.tlf.novell.com> <5279114B.9080405@eu.citrix.com> <52792326.4050206@eu.citrix.com> <527927E3.3000004@eu.citrix.com> <1383730770.9207.93.camel@Solace> <527A1DFC0200007800100033@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7636623202439438686==" Return-path: Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1VdzuO-0005CO-Kq for xen-devel@lists.xenproject.org; Wed, 06 Nov 2013 10:00:20 +0000 In-Reply-To: <527A1DFC0200007800100033@nat28.tlf.novell.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: Jan Beulich Cc: MarcusGranado , Justin Weaver , IanCampbell , Li Yechen , George Dunlap , Andrew Cooper , JuergenGross , Ian Jackson , Matt Wilson , xen-devel , Daniel De Graaf , KeirFraser , Elena Ufimtseva List-Id: xen-devel@lists.xenproject.org --===============7636623202439438686== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-Uzf4jOXm0ekW9gAPI7oH" --=-Uzf4jOXm0ekW9gAPI7oH Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On mer, 2013-11-06 at 09:46 +0000, Jan Beulich wrote: > >>> On 06.11.13 at 10:39, Dario Faggioli wrot= e: > > Now, we're talking about killing vc->cpu_affinity and not introducing > > vc->node_affinity and, instead, introduce vc->cpu_hard_affinity and > > vc->cpu_soft_affinity and, more important, not to link any of the above > > to d->node_affinity. That means all the above operations _will_NOT_ > > automatically affect d->node_affinity any longer, at least from the > > hypervisor (and, most likely, libxc) perspective. OTOH, I'm almost sure > > that I can force libxl (and xl) to retain the exact same behaviour it i= s > > exposing to the user (just by adding an extra call when needed). > >=20 > > So, although all this won't be an issue for xl and libxl consumers (or, > > at least, that's my goal), it will change how the hypervisor used to > > behave in all those situations. This means that xl and libxl users will > > see no change, while folks issuing hypercalls and/or libxc calls will. > >=20 > > Is that ok? I mean, I know there are no stability concerns for those > > APIs, but still, is that an acceptable change? >=20 > I would think that as long as d->node_affinity is empty, it should > still be set based on all vCPU-s' hard affinities=20 > I see, and that sounds sensible to me... It's mostly a matter a matter of deciding whether o not we want something like that, and, if yes, whether we want it based on hard of soft. Personally, I think I agree with you on having it based on hard affinities by default. Let's see if George get to say something before I get to that part of the (re)implementation. :-) > (as it is an error - > possibly to be interpret as "do this for me" to try to set an empty > node affinity there's no conflict here). Or alternatively a flag > could be set once it got set, preventing further implicit updates. >=20 Sure. It's actually quite similar to that already. Both in the tree and in the series, affinity to none is just error, affinity to all means "do it for me", and I do have the flag there. I can easily change this into what you're suggesting (i.e., make none =3D> "do it for me"). Regards, Dario --=20 <> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) --=-Uzf4jOXm0ekW9gAPI7oH 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.15 (GNU/Linux) iEYEABECAAYFAlJ6EyAACgkQk4XaBE3IOsSl/ACcC94BP1sfi632+xqewvCNRmH2 EugAn3jeFZky2JHhLzzZuilwL2mQce4s =fqr0 -----END PGP SIGNATURE----- --=-Uzf4jOXm0ekW9gAPI7oH-- --===============7636623202439438686== 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 --===============7636623202439438686==--