From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli Subject: Re: [DOC RFC] Heterogeneous Multi Processing Support in Xen Date: Thu, 8 Dec 2016 22:54:04 +0100 Message-ID: <1481234044.3445.182.camel@citrix.com> References: <1481135379.3445.142.camel@citrix.com> <584940B00200007800126A04@prv-mh.provo.novell.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0557561129828984113==" Return-path: In-Reply-To: <584940B00200007800126A04@prv-mh.provo.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xen.org Sender: "Xen-devel" To: Jan Beulich Cc: Juergen Gross , Peng Fan , Stefano Stabellini , George Dunlap , AndrewCooper , Xen Devel , anastassios.nanos@onapp.com, Peng Fan List-Id: xen-devel@lists.xenproject.org --===============0557561129828984113== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="=-Kk9qRrBjUEztoY9fJBc6" --=-Kk9qRrBjUEztoY9fJBc6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, 2016-12-08 at 03:14 -0700, Jan Beulich wrote: > > > > On 07.12.16 at 19:29, wrote: > > The list of classes is kept ordered from the more powerful to the > > less > > powerful. > > **TODO:** this has been [proposed by=C2=A0 > > George](https://lists.xenproject.org/archives/html/xen-devel/2016-0 > > 9/msg02212.html). > > I like the idea, what do others think? If we agree on that, note > > that there > > has been no discussion on defining what "more powerful" means, > > neither on > > x86 (although, not really that interesting, for now, I'd say), nor > > on ARM. >=20 > Indeed I think there should be no assumption about the ability to > order things here: Even if for some initial set of hardware it may > be possible to clearly tell which one's more powerful and which > one's more weak, already the moment you extend this from > compute power to different ISA extensions you'll immediately end > up with the possibility of two CPUs have a distinct extra feature > compared to one another (say one a crypto extension and the > other a wider vector compute engine). >=20 Yeah, that was what was puzzling me too. Keeping them ordered has the nice property that if a user says the following in a config file: =C2=A0vcpuclass=3D["0-3:class0", "4-7:class1"] (assuming that class0 and class1 are the always available Xen names) it would be always true that vCPUs 0-3 are 'more powerful', no matter on what host the VM runs (ARM and x86, now and in 5 years, etc), which would be really nice. But I really am not sure whether that is possible. Perhaps George, which thought about this first, has it more clear... Thanks and Regards, Dario --=20 <> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) --=-Kk9qRrBjUEztoY9fJBc6 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 iQIcBAABCAAGBQJYSdZ8AAoJEBZCeImluHPusFIQALtkeGZ6AKrYP1gpNF2438Kx 3Fv2SPy7zXXGIXyIercQxvPBJs16nDGJx+ynSdA1i+PTbhuF3rVXpa4pZbqmCgWK 0yXpFavQlohHJABtYZ+dMX9rKWpRBnb1vG7GAvcHAgSpbFsWMFwOvpmZcROEWMR/ QhkoJ+/n/nW6NgfI8sBU0yWnlueNK8L9D3T4+ko2EE+CGxeF6R4KMzVyiF45gf0w 8vntW30YXaYtHeUFC7IOB/7zxjb+Ezirmh5bVFl5x7U5MQXurTe6JTo9LXLaRID2 McqPoF5j0rHXttOjiM9Kbzt67CYr/5vPIzkKD+kzIXyyUbpvOgiOEWQZdiDDzvZ/ 2MuX00iylfE1bdhbF8qytA2yvje+mY+prUvdroM+Ewl1L8Perc5fwzxHbxYY4PTK MbHCteek2M5MM85dgYmQuBwXzowkgYW1pDXeUPGgRmX+d/95eaKu004r71D4MRrp y6GrRMApegf58/dAtNMKHhMFd5EJrbxbmfqxrD7H8wXYV18FxkJePHbTM6DG/m5n hVpvoDdvl+SZ27CIZmujyqB5if/dl6/g+gDwzeAi244Tp3Lxb3Y0NF0oLnpzffeu RvnvGig2TeoSMbggs9jsY8qvE36q9v1zxpsVjGrPbZhcZcbss9G5t766YZM06GwB JygnAO9gVUecwfJ0/5P7 =OQGz -----END PGP SIGNATURE----- --=-Kk9qRrBjUEztoY9fJBc6-- --===============0557561129828984113== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwczovL2xpc3RzLnhlbi5v cmcveGVuLWRldmVsCg== --===============0557561129828984113==--