linux-kernel - Re: [PATCH] perf_events: add PERF_SAMPLE_BRANCH

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 7 Apr 2010 18:48:19 +0200
From:	Stephane Eranian <eranian@...gle.com>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	linux-kernel@...r.kernel.org, mingo@...e.hu, paulus@...ba.org,
	davem@...emloft.net, fweisbec@...il.com, robert.richter@....com,
	perfmon2-devel@...ts.sf.net, eranian@...il.com
Subject: Re: [PATCH] perf_events: add PERF_SAMPLE_BRANCH_STACK

On Wed, Apr 7, 2010 at 3:15 PM, Peter Zijlstra <peterz@...radead.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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/