From mboxrd@z Thu Jan 1 00:00:00 1970 From: Chao Peng Subject: Re: [RFC PATCH 0/7] Intel Cache Monitoring: Current Status and Future Opportunities Date: Wed, 8 Apr 2015 13:59:16 +0800 Message-ID: <20150408055916.GF3404@pengc-linux.bj.intel.com> References: <20150404020423.22875.23590.stgit@Solace.station> <5523B0FB.8020509@citrix.com> <1428412199.5671.94.camel@citrix.com> Reply-To: Chao Peng Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <1428412199.5671.94.camel@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Dario Faggioli Cc: Wei Liu , Ian Campbell , Andrew Cooper , George Dunlap , "xen-devel@lists.xen.org" , "JBeulich@suse.com" List-Id: xen-devel@lists.xenproject.org > > "max_rmid" is a per-socket property. There is no requirement for it to > > be the same for each socket in a system, although it is likely, given a > > homogeneous system. > > > I know. Again this was not mentioned for document length reasons, but I > planned to ask about this (as I've done that already this morning, as > you can see. :-D). > > In this case, though, it probably was something worth being mentioned, > so I will if there will ever be a v2 of the document. :-) > > Mostly, I was curious to learn why that is not reflected in the current > implementation, i.e., whether there are any reasons why we should not > take advantage of per-socketness of RMIDs, as reported by SDM, as that > can greatly help mitigating RMID shortage in the per-CPU/core/socket > configuration (in general, actually, but it's per-cpu that I'm > interested in). Andrew is right, RMID is a per-socket property. One reason it's not used in current implementation, I think, is the fact that max_rmid is normally the same among sockets, though they can be different in theory. So the same RMID is targeted for all the sockets. But per-socketness of RMIDs can be used anyway. We do take this into account for CAT. > > As far as MSRs themselves go, an extra MSR write in the context switch > > path is likely to pale into the noise. However, querying the data is an > > indirect MSR read (write to the event select MSR, read from the data > > MSR). Furthermore there is no way to atomically read all data at once > > which means that activity on other cores can interleave with > > back-to-back reads in the scheduler. > > > All true. And in fact, how and how frequent data should be gathered > remains to be decided (as said in the document). I was thinking more to > some periodic sampling, rather than to throw handfuls of rdmsr/wrmsr > against the code that makes scheduling decisions! :-D Due to current hardware limitations and in the case of scheduling improvement, periodic sampling sounds a feasible direction to me. Chao