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

[Chao Peng <chao.p.peng@xxxxxxxxxxxxxxx>]

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

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