Re: perf_counters issue with PERF_SAMPLE_GROUP

[stephane eranian <eranian@googlemail.com>]

On Wed, Aug 12, 2009 at 11:02 AM, Ingo Molnar<mingo@elte.hu> wrote:
>
> * Peter Zijlstra <a.p.zijlstra@chello.nl> wrote:
>
>> On Tue, 2009-08-11 at 23:08 +0200, stephane eranian wrote:
>>
>> > But aren't you going to change the cpu, pid target stuff we
>> > discussed a couple of weeks ago anyway?
>>
>> Right, I'd like to, but Ingo doesn't. I haven't heard back from
>> Paul on this.
>
> Not sure we want to change it. Mixing PID and CPU into the same
> space disallows the simultaneous application of both. I.e. right now
> we allow 3 models:
>
>  - PID-ish
>  - CPU-ish
>  - PID and CPU [say measure CPU#2 component of an inherited workload.]
>
How useful is that last model, especially why only one CPU?

> Also, i dont really see the use-cases for new targets. (i've seen a
> few mentioned but none seemed valid) What new targets do people have
> in mind?

I seem to recall people mentioned:
   1- CPU socket, e.g., uncore PMU
   2- chipset
   3- GPU

I can see 1/ being indirectly achievable by specifying a CPU.
But the others are uncorrelated to either a CPU or thread.
I have already seen requests for accessing chipsets, and
seems GPU are around the corner now.

Why do you think those would be invalid targets given
the goal of this API?