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

[Dario Faggioli <dario.faggioli@citrix.com>]

[-- Attachment #1.1: Type: text/plain, Size: 1529 bytes --]

On Tue, 2015-04-07 at 16:19 +0800, Chao Peng wrote:
> On Sat, Apr 04, 2015 at 04:14:15AM +0200, Dario Faggioli wrote:

> > I'm putting here in the cover letter a markdown document I wrote to better
> > describe my findings and ideas (sorry if it's a bit long! :-D). You can also
> > fetch it at the following links:
> > 
> >  * http://xenbits.xen.org/people/dariof/CMT-in-scheduling.pdf
> >  * http://xenbits.xen.org/people/dariof/CMT-in-scheduling.markdown
> > 
> > See the document itself and the changelog of the various patches for details.
> 
> Very good summary and possible usage analysis. 
>
Thanks. :-)

> Most of the problems do
> exist and some of them may be solved partially but some looks
> unavoidable.
> 
I see.

> > It is rather easy to appreciate that any kind of 'flushing' mechanism, to be
> > triggered when reusing an RMID (if anything like that even exists!) would
> > impact system performance (e.g., it is not an option in hot paths), but the
> > situation outlined above needs to be fixed, before the mechanism could be
> > considered usable and reliable enough to do anything on top of it.
> 
> As I know, no such 'flushing' mechanism available at present. One
> possible software solution to lighten this issue is rotating the RMIDs
> with algorithm like 'use oldest unused RMID first'.
> 
Ok. Yes, that was something I was thinking to as well. It certainly
would make the issue less severe / less likely to happen.

Let's see what others think.

Regards,
Dario

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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