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

[Dario Faggioli <dario.faggioli@xxxxxxxxxx>]

On Wed, 2015-04-08 at 12:30 +0100, George Dunlap wrote:
> On 04/04/2015 03:14 AM, Dario Faggioli wrote:
> > ### Per-vCPU cache monitoring
> > 
> > This means being able to tell how much of the L3 is being used by each vCPU.
> > Monitoring the cache occupancy of a specific domain, would still be 
> > possible,
> > just by summing up the contributions from all the domain's vCPUs.
> 
> One note about this -- vcpu cache utilization may be predictive
> short-term, but long-term it's probably less important because the guest
> may move processes between vcpus.
>
True. That, however, applies to any measurements / estimation of
per-vcpu load, for any definition of 'load', doesn't it? So, yes we can
use it for short term decisions and/or time-average it (i.e., exactly as
we do with per-vcpu and runqueue load, e.g., in Credit2).

>   So it may make sense to leave the
> occupancy stats on a per-domain basis anyway.
> 
Indeed, but then I'm not sure I see a way to use that stats, at least
not from inside the scheduler (if we're talking about this), do you?

> Thoughts?
> 
IMO, a nice way to use CMT in a per-vcpu configutation, from within the
scheduler, would have been to know, for a given vcpu, how much of the
data it uses are (still) resident on a given cache layer of a given pCPU
at a given time instant. That sort of info could have been used to
decide whether it is wise to move the vcpu away of that pCPU or not, in
a way that is complementary to other metrics which we already have,
and/or, in general, that can be implemented in software (e.g. load
average stats).

Doing that, however, requires too many RMIDs, and it's not terribly
useful if done on L3. Therefore, I think that investing time in enabling
and trying to exploit per-*pCPU* monitoring.

Thoughts? :-D

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