Re: perf_counters issue with PERF_SAMPLE_GROUP

[Ingo Molnar <mingo@elte.hu>]

* stephane eranian <eranian@googlemail.com> wrote:

> On Wed, Aug 12, 2009 at 11:02 AM, Ingo Molnar<mingo@elte.hu> wrote:
>
> > 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?

It's somewhat useful: say on an inherited workload one could 'cut 
out' just a single CPU worth of samples.

Or a tool could implement a more scalable sampling model: say on a 
quad core CPU one could have four counters in an inherited workload:

  cycles:cpu0
  cycles:cpu1
  cycles:cpu2
  cycles:cpu3

... and depending on which CPU a sub-process or sub-thread is 
running on, would the according (nicely per cpu local) sampling 
buffer be used.

> > 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.

Correct.

( Note, it's not just indirectly achievable as a side-effect - for 
  example the Intel uncore PMU has a target CPU irq-mask, so it 
  makes sense to allow the specification of the specific CPU we are
  measuring on as well. The physical socket maps from the 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?

No.

Chipset and GPU measurements are very much possible via perfcounters 
as well - but that does not require the touching of the pid,cpu 
target parameters to sys_perf_counter_open().

I think the confusion in this discussion comes from the fact that 
there are two different types of 'targets':

The first type of target, the <pid,cpu> target is a _scheduling_, 
task management abstraction. Adding a chipset ID or GPU ID to that 
makes little sense! Tasks dont get scheduled on a 'chipset' - to 
each task the chipset looks like an external entity.

The second type of target is the 'event source itself'. (and it's 
not really a target but a source.)

A chipset or GPU should be abstracted via an _event source_ 
abstraction. We've got wide possibilities to do that, and we already 
abstract a fair amount of non-CPU-sourced events that way: say we 
have irq tracepoint counters:

  aldebaran:~> perf list 2>&1 | grep irq
    irq:irq_handler_entry                      [Tracepoint event]

irqs come from the chipset, so in an (unintended) way perfcounters 
already instruments the chipset today.

So yes, both chipset and GPU sampling is very much possible, and it 
does not require the tweaking of the syscall target parameters - 
each CPU has a typically symmetric view on it.

Note that there's overlap: a CPU can be an event source and a 
scheduling target as well. I think some of the confusion in 
terminology comes from that.

To support chipset or GPU sampling, the perf_type_id and/or the 
struct perf_counter_attr space can be extended.

We'd have to see the patches to decide the best way forward - it's 
difficult to argue this hypothetically, as there are so many 
solutions (with different levels of complexity and utility) to 
expose chipsets and GPUs to perfcounters. In any case, the counter 
scheduling target parameters dont need to be touched for them.

	Ingo