From: Stephane Eranian <eranian@google.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: linux-kernel@vger.kernel.org, mingo@elte.hu, paulus@samba.org,
davem@davemloft.net, fweisbec@gmail.com, robert.richter@amd.com,
perfmon2-devel@lists.sf.net, eranian@gmail.com
Subject: Re: [PATCH] perf_events: add PERF_SAMPLE_BRANCH_STACK
Date: Wed, 7 Apr 2010 18:48:19 +0200 [thread overview]
Message-ID: <l2kbd4cb8901004070948zcc0fd6dcv8eb2431edd271c4e@mail.gmail.com> (raw)
In-Reply-To: <1270646127.20295.976.camel@laptop>
On Wed, Apr 7, 2010 at 3:15 PM, Peter Zijlstra <peterz@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.
next prev parent reply other threads:[~2010-04-07 16:48 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-04-07 12:45 Stephane Eranian
2010-04-07 13:15 ` Peter Zijlstra
2010-04-07 16:48 ` Stephane Eranian [this message]
2010-04-07 16:54 ` Peter Zijlstra
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=l2kbd4cb8901004070948zcc0fd6dcv8eb2431edd271c4e@mail.gmail.com \
--to=eranian@google.com \
--cc=davem@davemloft.net \
--cc=eranian@gmail.com \
--cc=fweisbec@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=paulus@samba.org \
--cc=perfmon2-devel@lists.sf.net \
--cc=peterz@infradead.org \
--cc=robert.richter@amd.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®