From mboxrd@z Thu Jan  1 00:00:00 1970
From: Dario Faggioli <dario.faggioli@citrix.com>
Subject: Re: [RFC Design Doc] Intel L2 Cache Allocation
 Technology (L2 CAT) Feature enabling
Date: Mon, 16 May 2016 11:44:29 +0200
Message-ID: <1463391869.18789.42.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> <1463156273.18789.38.camel@citrix.com>
 <20160516082357.GA17744@HE>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="===============8907790581733295654=="
Return-path: <xen-devel-bounces@lists.xen.org>
In-Reply-To: <20160516082357.GA17744@HE>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
 <mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
 <mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Errors-To: xen-devel-bounces@lists.xen.org
Sender: "Xen-devel" <xen-devel-bounces@lists.xen.org>
To: He Chen <he.chen@linux.intel.com>
Cc: Wei Liu <wei.liu2@citrix.com>, Andrew Cooper <andrew.cooper3@citrix.com>, Ian Jackson <ian.jackson@eu.citrix.com>, xen-devel@lists.xen.org, Jan Beulich <JBeulich@suse.com>, Chao Peng <chao.p.peng@linux.intel.com>
List-Id: xen-devel@lists.xenproject.org

--===============8907790581733295654==
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="=-3X82iB9gXiVwy+1pQyvu"

--=-3X82iB9gXiVwy+1pQyvu
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, 2016-05-16 at 16:23 +0800, He Chen wrote:
> As Andrew said, CLOS is currently managed per-domain in Xen and it
> works
> well so far. So in initial design, I am inclined to continue this
> behavior (per-socket) to L2 CAT to keep the consistency between L2
> and
> L3 CAT. Any thoughts?
>=20
FWIW, I think this is fine. If at some point we'll want something
different, we can always extend.

Perhaps, let's keep this (the fact that we may want to make things more
fine grained) in mind when designing the interface.

Regards,
Dario

--=20
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


--=-3X82iB9gXiVwy+1pQyvu
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

iQIcBAABCAAGBQJXOZZ+AAoJEBZCeImluHPuMEsQAJMxSufRfAfBgqCaz/rrAJOH
L7JqWCLPLvmQ3jvXYkjSFJXoA7yUfn4SKzNpfW/4XNDZntmUgCEshJ+bAWSTlqQe
YR1lr9j9lB6xb1TJLeMi8PEQHf9u11ThhUfB8E5aylFtsxy4zncRnku2vVMgOTAq
YsXbu3/6zsPWZosT6saALzhvWPOpXUsSq0JW3sXMnod37XCmL2JfWCkW1cD9UlSc
CK1hlMej4FGhCLfgIn9wXD6pDHzKMyAif+S/pxyFPnyeLnGx4oX98qcXcJw7ZW0o
JHYhFYLeD4+YgFV8znikiYKe64eVfY55x8rvzRdRqp3NB4nUM6krh4E4yLPTOAaR
ohYfW1z5W0I54a8J9DzZMZZ84LTyJarV5OPyOY1I65NvhglZhy7n0jYdEVIx15fy
IZduEGgmmWakaognQUg5bGlGBMFyOWH6sAPglzY51DyuBlUCHhNNQg5gU9kVSG5y
h7aZ80mJWe2w3hmNk0zbIqDRBkB6l2i4juTk44wk3QBOqeGPzE5+Q8+zaaLoyw8E
7qbkIn+b4JR626yMKlWGyUM/Il2xijjPLPTaKh3/tO07H7fA5JAJG5icgTXVQLlp
ctRMQT28p1vjHhduCe2UvOPo3gJBdaH0n1zu+3FJ5QHS6yssnrVFKK9eHp6IRG78
MoHPFEzrDhkPgNKEmoZH
=p5Wc
-----END PGP SIGNATURE-----

--=-3X82iB9gXiVwy+1pQyvu--


--===============8907790581733295654==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: inline

X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs
IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9y
Zy94ZW4tZGV2ZWwK

--===============8907790581733295654==--