Re: [Xen-devel] [RFC PATCH 3/7] xen: psr: reserve an RMID for each core

[Dario Faggioli <dario.faggioli@xxxxxxxxxx>]

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

> >     'persocket_cmt' would basically only allow to track the
> >     amount of free L3 on each socket (by subtracting the
> >     monitored value from the total). Again, still better
> >     than nothing, would use very few RMIDs, and I could
> >     think of ways of using this information in a few
> >     places in the scheduler...
> > 
> >     Again, thought?
> 
> This even can be extended to the concept of 'cache monitoring group',
> which can hold arbitrary cpus into one group. 
>
Yes, indeed.

> Actually Linux
> implementation does this by using the cgoup mechanism to allocate RMID
> to a group of threads. 
>
Does it? I dig the threads of the Linux's patches up to a certain point,
and it seemed that the maintainer disliked the idea of PSR-cgroups. I
have to admit I stopped at some point, and did not check how the
checked-in code actually looks like.

Anyway, yes, I'll explore the 'grouping idea'. In fact, in order to be
able to use CMT (and other PSR features) from inside the scheduler, the
shortage of RMIDs is probably not the biggest issue.

I'm much more concerned about the difficulties in making both "static"
monitoring (i.e., the per-core/per-group monitoring required by the
scheduler and other Xen components) and "dynamic" monitoring (i.e., the
per-domain monitoring, happening on user request, via `xl
psr-cmt-attach') play well together, if enabled at the same time.

If you've got time and are interested in providing your view on that, it
would be great.

> Such design can solve the RMID-shortage somehow.
> 
Exactly. Actually, I've got a question: I think I remember reading on
Intel's SDM that RMID makes sense per-socket. If that is the case, it
means I can use, say, RMID #18 for both core 4, on socket 0, and core
73, on socket 2, do you confirm that? I'm asking because, as I said, I
think I read it in the manual, but the Xen implementation does not seem
to take advantage of this (perhaps because it wasn't necessary?).

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