[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
Description: This is a digitally signed message part

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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.