[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [RFC PATCH 0/7] Intel Cache Monitoring: Current Status and Future Opportunities
On Wed, 2015-04-08 at 13:59 +0800, Chao Peng wrote: > > 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. > Yeah, but rather than to the maximum number of available RMIDs, what I'm much interested in is whether I can use _the_ _same_ RMID for different cores, if they belong to different sockets. AFAIUI, it is possible, is that correct? > > 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. > Good to know, thanks. Regards, Dario Attachment:
signature.asc _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |