From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli Subject: Re: [RFC Design Doc] Intel L2 Cache Allocation Technology (L2 CAT) Feature enabling Date: Fri, 13 May 2016 18:17:53 +0200 Message-ID: <1463156273.18789.38.camel@citrix.com> References: <20160512094018.GA966@HE> <5734719002000078000EADCC@prv-mh.provo.novell.com> <20160513062641.GA10649@HE> <573594CB02000078000EB18F@prv-mh.provo.novell.com> <7bf4a5cf-42cc-aac1-ce86-7e24659a9cd1@citrix.com> <5735B28402000078000EB1DE@prv-mh.provo.novell.com> <57359D05.30407@citrix.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6582727217886408129==" Return-path: In-Reply-To: <57359D05.30407@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xen.org Sender: "Xen-devel" To: Andrew Cooper , Jan Beulich , He Chen Cc: Wei Liu , Ian Jackson , ChaoPeng , xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org --===============6582727217886408129== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="=-BGuPWQ8Ikxr2Ga5gAGze" --=-BGuPWQ8Ikxr2Ga5gAGze Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, 2016-05-13 at 10:23 +0100, Andrew Cooper wrote: > On 13/05/16 09:55, Jan Beulich wrote: > >=C2=A0 > > But anyway, L2 or L3 - I can't see how this context switching would > > DTRT when there are vCPU-s of different domains on the same > > socket (or core, if L2s and MSRs were per-core): The one getting > > scheduled later onto a socket (core) would simply overwrite what > > got written for the one which had been scheduled earlier. > PSR_ASSOC is a per-thread MSR which selects the CLOS to use.=C2=A0=C2=A0C= LOS is > currently managed per-domain in Xen, and context switched with vcpu. >=20 Yep, exactly. I did look a bit into this for CMT (so, not L3 CAT, but it's not that different). Doing things on a per-vcpu basis could be interesting, and that's even more the case if we get to do L2 stuff, but there are two few RMIDs available for such a configuration to be really useful. > Xen programs different capacity bitmaps into IA32_L2_QOS_MASK_0 ... > IA32_L2_QOS_MASK_n, and the CLOS selects which bitmap is enforced. >=20 So, basically, just to figure out if I understood (i.e., this is for He Chen). If we have a 2 sockets, with socket 0 containing cores 0,1,2,3 and socket 1 containing cores 4,5,6,7, it will be possible to specify two different "L2 reservation values" (in the form of CBMs, of course), for a domain: =C2=A0- one would be how much L2 cache the domain will be able to use (say= =C2=A0 =C2=A0 =C2=A0X) when running on socket 1, which means on cores 0,1,2 or 3 =C2=A0- another would be how much L2 cache the domain will be able to (say,= =C2=A0 =C2=A0 =C2=A0Y use when running on socket 2, which means on cores 4,5,6, or= 7 Which in turn means, in case L2 is per core, the domain will get X of core 0's L2, X of core 1's L2, X of core 2's L2 and X of core 3's L2. On socket 1, it will get Y of core 4' L2, Y of core 5's L2 cache etc. etc. And so, in summary what we would not be able to specify is a different value for the L2 reservations of, for instance, core 1 and core 3 (i.e., of cores that are part of the same socket). Does this summary make sense? 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) --=-BGuPWQ8Ikxr2Ga5gAGze 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 iQIcBAABCAAGBQJXNf4xAAoJEBZCeImluHPuTvAP/22Ys54grnezkXZI/WwMJALw 3ASW5rBXH0evIgUiohFLnZ9SC4wNtILlcfYhS2e2u0UZ20AfNANxQctXu/X/vs7t /ULJIfLh8z4EcfUujn4qPMZ3hETB6LGLDlJM+Gf+y8eFQmJiWnm1HFjDvFgHDc7y Mh+nIuENoK6oGepf5aE/DHMtrd1Y4uQTkL0+fQ4xXpqexPKcINd0Gwv62YMjBE6a H8Ha5hremwGug4JYBglxLHq2Q98Dm6hYR6hP/9xGSfmwgBOup9Cq1yDOwnQBw1gp cQ9Kq1RYcC8/g9v7SXFTDUJeLEyD5RqfSCB/IUPwIPQ0bro8Y3smXkDMIM2kxzlL 3yQ9ixJ/NRagszu0GknFmbWFOhfCFiESMDGGtzqUlLeuK0k1z9iaRuaDWiDfPL60 6teDb1oQptI1NHdW/5TTxZDV1jZxzRCEDz1z/0W5F3RpSViF83dFRgfc7fp52GlA x5Id5RxLntB3jzQZ113YYKqU21rKTSRm5iXgaMxkYtM7IVkx1tUxLDIZx8+Ko09v A9y780h8pJp+vqEptIA05lGb1kfkRqIC/Ucx1qbuAbGzgBNDPBEgoYS7M4kiTQGn TkJWQjQuuWChKlqsPTyhg2h7zvCKiBRfYSUy0ddwt6eUMUX7/NoJy8tOJ8/3uYFO FY1K9F18I1BdUsG245YQ =djdv -----END PGP SIGNATURE----- --=-BGuPWQ8Ikxr2Ga5gAGze-- --===============6582727217886408129== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9y Zy94ZW4tZGV2ZWwK --===============6582727217886408129==--