Re: [Xen-devel] [RFC PATCH 0/7] Intel Cache Monitoring: Current Status and Future Opportunities

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 08/04/15 09:23, Dario Faggioli wrote:
> 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?

It is perfectly possible to track the same logical resource using
different RMIDs on different sockets.

~Andrew

>
>>> 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


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel