Messages in this thread | | | Date | Wed, 12 Aug 2009 14:22:25 +0200 | Subject | Re: perf_counters issue with PERF_SAMPLE_GROUP | From | stephane eranian <> |
| |
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? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |