From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli Subject: Re: [RFC PATCH 0/7] Intel Cache Monitoring: Current Status and Future Opportunities Date: Wed, 8 Apr 2015 13:16:39 +0000 Message-ID: <1428498241.5671.124.camel@citrix.com> References: <20150404020423.22875.23590.stgit@Solace.station> <55251154.3020807@eu.citrix.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7384285206640197832==" Return-path: In-Reply-To: <55251154.3020807@eu.citrix.com> Content-Language: en-US List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: George Dunlap Cc: Wei Liu , Ian Campbell , Andrew Cooper , "xen-devel@lists.xen.org" , "JBeulich@suse.com" , "chao.p.peng@linux.intel.com" List-Id: xen-devel@lists.xenproject.org --===============7384285206640197832== Content-Language: en-US Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-4HTwfQ+9dTprMPjDp8Ne" --=-4HTwfQ+9dTprMPjDp8Ne Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, 2015-04-08 at 12:30 +0100, George Dunlap wrote: > On 04/04/2015 03:14 AM, Dario Faggioli wrote: > > ### Per-vCPU cache monitoring > >=20 > > This means being able to tell how much of the L3 is being used by each = vCPU. > > Monitoring the cache occupancy of a specific domain, would still be pos= sible, > > just by summing up the contributions from all the domain's vCPUs. >=20 > One note about this -- vcpu cache utilization may be predictive > short-term, but long-term it's probably less important because the guest > may move processes between vcpus. > True. That, however, applies to any measurements / estimation of per-vcpu load, for any definition of 'load', doesn't it? So, yes we can use it for short term decisions and/or time-average it (i.e., exactly as we do with per-vcpu and runqueue load, e.g., in Credit2). > So it may make sense to leave the > occupancy stats on a per-domain basis anyway. >=20 Indeed, but then I'm not sure I see a way to use that stats, at least not from inside the scheduler (if we're talking about this), do you? > Thoughts? >=20 IMO, a nice way to use CMT in a per-vcpu configutation, from within the scheduler, would have been to know, for a given vcpu, how much of the data it uses are (still) resident on a given cache layer of a given pCPU at a given time instant. That sort of info could have been used to decide whether it is wise to move the vcpu away of that pCPU or not, in a way that is complementary to other metrics which we already have, and/or, in general, that can be implemented in software (e.g. load average stats). Doing that, however, requires too many RMIDs, and it's not terribly useful if done on L3. Therefore, I think that investing time in enabling and trying to exploit per-*pCPU* monitoring. Thoughts? :-D Thanks and Regards, Dario --=-4HTwfQ+9dTprMPjDp8Ne 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 iEYEABECAAYFAlUlJ0IACgkQk4XaBE3IOsQStwCfeBazHj4VP75kfRTLp3m06E9o /2AAnRNCJ5hCngRuL/heJ7UvaTkbxcyT =U+Xs -----END PGP SIGNATURE----- --=-4HTwfQ+9dTprMPjDp8Ne-- --===============7384285206640197832== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============7384285206640197832==--