Re: [PATCH] perf_events: add PERF_SAMPLE_BRANCH_STACK
From: Stephane Eranian
Date: Wed Apr 07 2010 - 12:48:28 EST
On Wed, Apr 7, 2010 at 3:15 PM, Peter Zijlstra <peterz@xxxxxxxxxxxxx> 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:
> 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
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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/