From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli Subject: Re: [RFC PATCH 3/7] xen: psr: reserve an RMID for each core Date: Tue, 7 Apr 2015 10:19:22 +0000 Message-ID: <1428401960.5671.27.camel@citrix.com> References: <20150404020423.22875.23590.stgit@Solace.station> <20150404021441.22875.9924.stgit@Solace.station> <20150406135956.GE12596@l.oracle.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1611003766915120011==" Return-path: In-Reply-To: <20150406135956.GE12596@l.oracle.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: "konrad.wilk@oracle.com" Cc: Wei Liu , Ian Campbell , Andrew Cooper , George Dunlap , "xen-devel@lists.xen.org" , "JBeulich@suse.com" , "chao.p.peng@linux.intel.com" List-Id: xen-devel@lists.xenproject.org --===============1611003766915120011== Content-Language: en-US Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-5MHEyg+gzHxjTbRjLh1d" --=-5MHEyg+gzHxjTbRjLh1d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, 2015-04-06 at 09:59 -0400, Konrad Rzeszutek Wilk wrote: > On Sat, Apr 04, 2015 at 04:14:41AM +0200, Dario Faggioli wrote: > > XXX Another idea I just have is to allow the user to > > somehow specify a different 'granularity'. Something > > like allowing 'percpu_cmt'|'percore_cmt'|'persocket_cmt' > > with the following meaning: > > + 'percpu_cmt': as in this patch > > + 'percore_cmt': same RMID to hthreads of the same core > > + 'persocket_cmt': same RMID to all cores of the same > > socket. > >=20 > > 'percore_cmt' would only allow gathering info on a > > per-core basis... still better than nothing if we > > do not have enough RMIDs for each pCPUs. >=20 > Could we allocate nr_online_cpus() / nr_pmids() and have > some CPUs share the same PMIDs? >=20 Mmm... I hope we can (see the reply to Chao about the per-socketness nature of the RMIDs). I'm not sure what you mean here, though. In the box I have at hand there are 144 CPUs and 71 RMIDs. So, 144/71=3D2... maybe I'm missing something of what you mean, how should I use these 2 RMIDs? If RMIDs actually are per-socket, extending the existing Xen support to reflect that, and take advantage of it would help a lot already. In such box, it would mean I could use RMIDs 1-36, on each socket, per per-CPU monitoring, and still have 35 RMIDs free (which could be 35x4=3D140, depending *how* we extend te support to match the per-socket nature of RMIDs). Let's see if that is confirmed... Of course, I can book the box again here and test it myself (and will do that, if necessary :-D). Thanks and Regards, Dario --=-5MHEyg+gzHxjTbRjLh1d 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 iEYEABECAAYFAlUjrygACgkQk4XaBE3IOsRBfACeLdFJ7qpySo4g3vxy+9vPaO/E IB8An1cYU32S0aH3494MlYEvLW1M2j+u =yGX0 -----END PGP SIGNATURE----- --=-5MHEyg+gzHxjTbRjLh1d-- --===============1611003766915120011== 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 --===============1611003766915120011==--