Re: [patch] Performance Counters for Linux, v4

[Ingo Molnar <mingo@elte.hu>]

* Maynard Johnson <maynardj@us.ibm.com> wrote:

> > Over time, it seems clear that we will see multi-core processor 
> > designs with increasingly large uncore/nest facilities, so this could 
> > become more and more of an issue.

> Ingo, I'll add my voice to the chorus here.  To reiterate the point, 
> some PMUs count events that are external to the processor cores, and 
> these events cannot be attributed to any one particular CPU -- and 
> certainly not to a particular pid.  The current interface has a 
> restriction that the user cannot pass -1 for both pid and cpu.  But it 
> seems to me that's exactly what would be needed for such off-core 
> events.  Can this feature fit in with the current interface or is some 
> sort of extension needed?

They fit in just fine, they just will have constraints that dont allow 
their scheduling in a conflicting way. I.e. you'll only be able to occupy 
it from a single counter per physical package - but otherwise it still 
behaves like a normal counter if you define a single such counter per 
physical package, as a percpu counter. (they dont make much sense as task 
counters)

Btw., those kind of constraints make them quite noisy and hard to 
interpret as well - because they summarize per physical package 
characteristics (of up to 8 logical CPUs on Nehalem for example) and 
cannot be tied to tasks easily.

I'm not dismissing them entirely: they do give an overview of "all stuff 
that happens" at that level, and they do show a few things that is 
obviously tied to the 'uncore' of a CPU (the cache, the memory interlink, 
etc.), which cannot be provided by the normal PMCs - but they are too 
highlevel to really be useful for finegrained analysis and for eventing.

In any case, despite their limitations they can still be provided just 
fine, and any limitations they have is an inherent limitation of those 
hardware counters, not of the perfcounters framework.

	Ingo