From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli Subject: Re: [PATCH v6 03/18] xl / libxl: push VCPU affinity pinning down to libxl Date: Tue, 10 Jun 2014 17:59:01 +0200 Message-ID: <1402415941.16827.64.camel@Solace> References: <1402317809-26833-1-git-send-email-wei.liu2@citrix.com> <1402317809-26833-4-git-send-email-wei.liu2@citrix.com> <1402408860.1250.136.camel@kazak.uk.xensource.com> <20140610140647.GM11959@zion.uk.xensource.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7753358945625194229==" Return-path: In-Reply-To: <20140610140647.GM11959@zion.uk.xensource.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: Wei Liu Cc: ian.jackson@eu.citrix.com, Ian Campbell , xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org --===============7753358945625194229== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-MZyvZ8VANiUtZNgc5nfF" --=-MZyvZ8VANiUtZNgc5nfF Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On mar, 2014-06-10 at 15:06 +0100, Wei Liu wrote: > On Tue, Jun 10, 2014 at 03:01:00PM +0100, Ian Campbell wrote: > > On Mon, 2014-06-09 at 13:43 +0100, Wei Liu wrote: > > > diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.id= l > > > index 0ea0464..4765fb6 100644 > > > --- a/tools/libxl/libxl_types.idl > > > +++ b/tools/libxl/libxl_types.idl > > > @@ -305,6 +305,7 @@ libxl_domain_build_info =3D > > > Struct("domain_build_info",[ > > > ("avail_vcpus", libxl_bitmap), > > > ("cpumap", libxl_bitmap), > > > ("nodemap", libxl_bitmap), > > > + ("vcpu_affinity", Array(libxl_bitmap, "num_vcpumaps")), > >=20 > > Looking at one of Dario's patches I became confused about how this new > > field relates to the existing cpumap field. > >=20 > > Am I right that the new field is just a per-vcpu version of the old > > (which only allows you to set the affinity of every vcpu together)? > >=20 >=20 > Yes, you're right. The old field denotes the PCPUs this domain is > allowed to run on. The new array specifies the PCPUs each VCPU can run > on. >=20 Well, there's no "new" and "old". I mean, as can clearly be seen in the hunk above, 'cpumap' is still there, and vcpu_affinity is being added. Fact is, considering how xl parses XXX in "cpus=3DXXX", only one between 'cpumap' and 'vcpu_affinity' will contain actual information. With my series on top of this one (or vice versa), we'll have: ("cpumap", libxl_bitmap) ("cpumap_soft", libxl_bitmap) ("vcpu_affinity", Array(libxl_bitmap, "num_vcpumaps")) which is missing the soft affinity equivalent of 'vcpu_affinity'. meaning that, either me or Wei, when rebasing on top of the other series which went in first, will have to add it, meaning we'll end up with the following: ("cpumap", libxl_bitmap) ("cpumap_soft", libxl_bitmap) ("vcpu_hard_affinity", Array(libxl_bitmap, "num_vcpumaps")) ("vcpu_soft_affinity", Array(libxl_bitmap, "num_vcpumaps")) which is a lot of fields, and not particularly easy to understand, IMHO. > > Can this relationship be mentioned in the commit message and/or comment= s > > please. > >=20 I think we could go farther than that... way farther. I mean, "cpumap" contains the vcpu affinity to be applied to all the vcpus of the domain, if the config file was something like "cpus=3D"1,3-6". "vcpu_affinity" contains a cpumap for each vcpu, if the config file was something like "cpus=3D["1", "5"] (and all this repeated for soft affinity, with my series). Can't we kill "cpumap" (and "cpumap_soft" too, in my series) and use "vcpu_affinity" (i.e., "vcpu_hard_affinity" and "vcpu_soft_affinity" after my series) only? What would happen is, in case we find "cpus=3D"4-5", we set all the bitmaps of "vcpu_hard_affinity" to "4-5". What do you think? Regards, Dario --=20 <> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) --=-MZyvZ8VANiUtZNgc5nfF 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.0.22 (GNU/Linux) iEYEABECAAYFAlOXK0UACgkQk4XaBE3IOsRhtwCfSpr/DSWLdmCpbsoaXXTl2NaU 34IAn3Mge9bHsqExKVXhSqM7iaAxY9jd =4wyy -----END PGP SIGNATURE----- --=-MZyvZ8VANiUtZNgc5nfF-- --===============7753358945625194229== 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 --===============7753358945625194229==--