perf_events: add PERF_SAMPLE_BRANCH_STACK
in [Kernel]
|
Prev: [PATCH] btusb: Raw mode and ACL/SCO data
Next: cpuhotplug: make get_online_cpus() scalability by using percpu counter
From: Peter Zijlstra on 7 Apr 2010 09:20 On Wed, 2010-04-07 at 14:45 +0200, Stephane Eranian wrote: > LBR is configured by default to record ALL taken branches. On some > processors, it is possible to filter the type of branches. This will > be supported in a subsequent patch. > > On other processors, the sample type is allowed but will generate a > sample where nr=0 as is the case with other sampling types. Right, so I already posted a patch like that: http://lkml.org/lkml/2010/3/4/160 and the reason its not merged is because there is no perf use-case for it. Ingo wants to avoid merging ABI bits for which there is no userspace around. We already have a few such things and we find that its too easy to regress on those part. So if you want this, please also implement a useful use-case in perf. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Stephane Eranian on 7 Apr 2010 12:50 On Wed, Apr 7, 2010 at 3:15 PM, Peter Zijlstra <peterz(a)infradead.org> wrote: > On Wed, 2010-04-07 at 14:45 +0200, Stephane Eranian wrote: >> LBR is configured by default to record ALL taken branches. On some >> processors, it is possible to filter the type of branches. This will >> be supported in a subsequent patch. >> >> On other processors, the sample type is allowed but will generate a >> sample where nr=0 as is the case with other sampling types. > > Right, so I already posted a patch like that: > http://lkml.org/lkml/2010/3/4/160 > > and the reason its not merged is because there is no perf use-case for > it. Ingo wants to avoid merging ABI bits for which there is no userspace > around. We already have a few such things and we find that its too easy > to regress on those part. > Then, why didn't you extend perf to leverage your patch? I think that forcing all features to be included in perf in not a very attractive approach. It can't be the only approach. There are many usage models of PMU data. You want to encourage the development of as many tools and libraries as possible. It helps with validation too. There are bugs in your implementation which are not exposed simply because perf does not need the features. But that does not mean those features are not useful. To encourage developers, you need to build simple examples of how each feature can be used. You don't necessarily need a fully featured tool. This is what I am doing with libpfm4. People can learn from the examples and built their own custom tools and libraries. If I post a patch to enable LBR sampling, it is because I have a user level test program to validate it and demonstrate what you can get out. LBR data typically has lots of post-processing. It is best suited for offline processing. You could use perf to collect the data and dump a binary output file. I can take a look at that. I also assume that the same reason is holding up my randomization patch. yet I think this is an important feature. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Peter Zijlstra on 7 Apr 2010 13:00
On Wed, 2010-04-07 at 18:48 +0200, Stephane Eranian wrote: > Then, why didn't you extend perf to leverage your patch? > Because I couldn't come up with a sensible use case. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |