From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli Subject: Re: [PATCH RFC 0/8] x86/hvm, libxl: HVM SMT topology support Date: Fri, 26 Feb 2016 16:42:42 +0100 Message-ID: <1456501362.2959.206.camel@citrix.com> References: <1456174934-22973-1-git-send-email-joao.m.martins@oracle.com> <56CF3822.80606@citrix.com> <1456499026.2959.195.camel@citrix.com> <20160226152743.GE17652@char.us.oracle.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4234387417873992141==" Return-path: In-Reply-To: <20160226152743.GE17652@char.us.oracle.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xen.org Sender: "Xen-devel" To: Konrad Rzeszutek Wilk , Elena Ufimtseva Cc: Wei Liu , Stefano Stabellini , Andrew Cooper , Ian Jackson , xen-devel@lists.xen.org, Jan Beulich , Keir Fraser , Joao Martins List-Id: xen-devel@lists.xenproject.org --===============4234387417873992141== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-vTWOdFeYJazLFfN+sQRU" --=-vTWOdFeYJazLFfN+sQRU Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, 2016-02-26 at 10:27 -0500, Konrad Rzeszutek Wilk wrote: > On Fri, Feb 26, 2016 at 04:03:46PM +0100, Dario Faggioli wrote: > >=C2=A0 > > > As part of my further cpuid work, I will need to fix this.=C2=A0=C2= =A0I was > > > planning to fix it by requiring full cpu topology information to > > > be > > > passed as part of the domaincreate or max_vcpus hypercall=C2=A0=C2=A0= (not > > > chosen > > > which yet).=C2=A0=C2=A0 >=20 > You may not want to make a full CPU topology to be exposed to the > guest. >=20 Right, but if I understood correctly (and, actually, to confirm that is what I'm asking), what's Andrew is saying does not mean "always expose the host topology". It means that a guest must have a (virtual) topology, and that topology can be Xen's default one, toolstack's default one, toolstack's default one when vcpu pinning is on, one that the administrator like, etc. > Elena (CCed) found some oddities and it actually looked like the > guest > performed _worst_ when it had this exposed and was floating (not- > pinned) > on machines with SMT enabled. >=20 Well, sure, that's something I would entirely expect. And in fact, more than better or worst, I remember the numbers you (well, she) posted to prove that exposing topology and letting the vcpu free to float leads to inconsistency and lack of predictability, which again is what I'd have predicted. :-) > > At that point, one can just build on top of that, in order to > > achieve > > something like what is implemented in this series, or any other > > variant > > of it, which would indeed be *awesome* (did I said that already? :- > > D). > Maybe you should lay off the coffee for a bit .. >=20 I also think that... but, you know, I'm in Italy, and here it's a crime not to have at least 4 coffees (=3D=3D espresso, of course!) during the day! ;-) Regards, Dario --=20 <> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) --=-vTWOdFeYJazLFfN+sQRU 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 iEYEABECAAYFAlbQcnIACgkQk4XaBE3IOsQ3aQCfRtCGjzI5hjXPQwrMElou/0d7 zpsAnidOAqqxT+s/eGdvO4Dx2zDJ0jOH =q9EN -----END PGP SIGNATURE----- --=-vTWOdFeYJazLFfN+sQRU-- --===============4234387417873992141== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9y Zy94ZW4tZGV2ZWwK --===============4234387417873992141==--