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: Tue, 7 Apr 2015 09:51:23 +0000 Message-ID: <1428400281.5671.1.camel@citrix.com> References: <20150404020423.22875.23590.stgit@Solace.station> <20150407081948.GB3404@pengc-linux.bj.intel.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2707138321516082904==" Return-path: In-Reply-To: <20150407081948.GB3404@pengc-linux.bj.intel.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: "chao.p.peng@linux.intel.com" Cc: Wei Liu , Ian Campbell , Andrew Cooper , George Dunlap , "xen-devel@lists.xen.org" , "dongxiao.xu@intel.com" , "JBeulich@suse.com" List-Id: xen-devel@lists.xenproject.org --===============2707138321516082904== Content-Language: en-US Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-hwEyXfyJJj8A8bcqvLKq" --=-hwEyXfyJJj8A8bcqvLKq Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, 2015-04-07 at 16:19 +0800, Chao Peng wrote: > On Sat, Apr 04, 2015 at 04:14:15AM +0200, Dario Faggioli wrote: > > I'm putting here in the cover letter a markdown document I wrote to bet= ter > > describe my findings and ideas (sorry if it's a bit long! :-D). You can= also > > fetch it at the following links: > >=20 > > * http://xenbits.xen.org/people/dariof/CMT-in-scheduling.pdf > > * http://xenbits.xen.org/people/dariof/CMT-in-scheduling.markdown > >=20 > > See the document itself and the changelog of the various patches for de= tails. >=20 > Very good summary and possible usage analysis.=20 > Thanks. :-) > Most of the problems do > exist and some of them may be solved partially but some looks > unavoidable. >=20 I see. > > It is rather easy to appreciate that any kind of 'flushing' mechanism, = to be > > triggered when reusing an RMID (if anything like that even exists!) wou= ld > > impact system performance (e.g., it is not an option in hot paths), but= the > > situation outlined above needs to be fixed, before the mechanism could = be > > considered usable and reliable enough to do anything on top of it. >=20 > As I know, no such 'flushing' mechanism available at present. One > possible software solution to lighten this issue is rotating the RMIDs > with algorithm like 'use oldest unused RMID first'. >=20 Ok. Yes, that was something I was thinking to as well. It certainly would make the issue less severe / less likely to happen. Let's see what others think. Regards, Dario --=-hwEyXfyJJj8A8bcqvLKq 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 iEUEABECAAYFAlUjqJoACgkQk4XaBE3IOsT4GACWPcS0Fk72tLPeXunCBmHhyZc/ SgCgmpRfQ7/4ytS6EE2E3B1gkEU2aa4= =DAH+ -----END PGP SIGNATURE----- --=-hwEyXfyJJj8A8bcqvLKq-- --===============2707138321516082904== 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 --===============2707138321516082904==--