From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli Subject: Re: [DOC RFC] Heterogeneous Multi Processing Support in Xen Date: Fri, 9 Dec 2016 09:29:37 +0100 Message-ID: <1481272177.3445.193.camel@citrix.com> References: <1481135379.3445.142.camel@citrix.com> <584940B00200007800126A04@prv-mh.provo.novell.com> <1481234044.3445.182.camel@citrix.com> <584A75C2020000780012716A@prv-mh.provo.novell.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5333062837845175733==" Return-path: In-Reply-To: <584A75C2020000780012716A@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 , StefanoStabellini , George Dunlap , AndrewCooper , Xen Devel , anastassios.nanos@onapp.com, Peng Fan List-Id: xen-devel@lists.xenproject.org --===============5333062837845175733== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="=-N/5etRbPKS153lHEdjma" --=-N/5etRbPKS153lHEdjma Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, 2016-12-09 at 01:13 -0700, Jan Beulich wrote: > > > > On 08.12.16 at 22:54, wrote: > > 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: > >=20 > > =C2=A0vcpuclass=3D["0-3:class0", "4-7:class1"] > >=20 > > (assuming that class0 and class1 are the always available Xen > > names) it >=20 > This, btw, is another aspect I think has a basic problem: class0 and > class1 say nothing about the properties of a class, and hence are > tied to one particular host. > The other way round, I'd say. I mean, since they say nothing, they're _not_ host specific? Anyway, naming was another thing on which the debate was not at all closed, but the point is exactly the one you're making here, in fact... > I think class names need to be descriptive > and uniform across hosts. That would allow migration of such VMs as > well as prevent starting them on a host not having suitable hardware. >=20 ...what George suggested (but please, George, when back, correct me if I'm misrepresenting your ideas :-)) that: =C2=A0- something generic, such as class0, class1 will always exist (well,= =C2=A0 =C2=A0 =C2=A0at least class0). They would basically constitute the Xen inte= rface; =C2=A0- toolstack will accept more specific names, such as 'big' and=C2=A0 =C2=A0 =C2=A0'little', and also 'A57' and 'A43' (I'm making up the names), = etc. =C2=A0- a VM with vCPUs in class0 and class1 will always be created and run= =C2=A0 =C2=A0 =C2=A0on any 2 classes system; a VM with big and little vCPUs will o= nly=C2=A0 =C2=A0 =C2=A0run on an ARM big.LITTLE incarnation; a VM with A57 and A43 vC= PUs=C2=A0 =C2=A0 =C2=A0will only run on an host that has at least one A57 and one A43= =C2=A0 =C2=A0 =C2=A0pCPUs. What's not clear to me is how to establish: =C2=A0- the ordering among classes; =C2=A0- the mapping between Xen's neuter names and the toolstack's (arch)= =C2=A0 =C2=A0 =C2=A0specific ones. All this being said, yes, if one specify more than one class and there's only one, as well as if one specify a class that does not exist, we should abort domain creation. I shall add this to the specs (it was covered in the thread, I just forgot). 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) --=-N/5etRbPKS153lHEdjma 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 iQIcBAABCAAGBQJYSmtyAAoJEBZCeImluHPupI0QAIUKDnkGPT+JWaIy5AHKM0q+ L3NDx1hUTb46zus3UTl9I4T+9mO5ySskMfhlF0HIerRELhURLbVVak/q2DkP6uN2 jH6qFIf0erzY/lGflLaciM07xvvp0GKyN7cWNyl+6NctERUvlaTJt6SgC94D5/cx 6BYZgNa+EMC9Oa0d8T4N0yJf0DkEELv0Uz9I9DWsPggBAK+brdNfgrcHJxzZzVKN bPkqTpuq/x6TsH/fuWlWUtGALdPzoTRIVIDsDKUVSPvxmB+Hwag7GRWwklcZSbE/ Zt3tdPEIuCS9eCF82Y/hLEHZSZ6SLHlZmOVWapn14KFQBuPMG5BTjJya6zE3mrad ynbw/VYe0prQYpleVALyTJ6zJYJXxDTPh8KiAkHCOjkQ/bBotd0VrwA0zlmb87E/ ev1I08yDGDvm6Iao0gww5J37ZPnWhWpQMF+MWeQjQgzLegtCmexWE3tvzzXAgxak u8uO781chVSBvuipUWOoj964DP+rKS4kjkCEIADxVIm6j+2fZWbp5XELM+g6ew94 nuLzhwYyAq1O6hrKZllsyNEltPRUB69I1B/7XehmYgyO5iS8WHyPn7iQCN+GroUv aIadKns+yz2s5bGBPFHWzjBjhPnt3roPu5Y0qmzEXbf2euUA7rPgwZSgQnyKrKXt jGweDqwq/JiVrfv/GsdY =ZQgP -----END PGP SIGNATURE----- --=-N/5etRbPKS153lHEdjma-- --===============5333062837845175733== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwczovL2xpc3RzLnhlbi5v cmcveGVuLWRldmVsCg== --===============5333062837845175733==--