[PATCH] perf_events: add PERF_SAMPLE_BRANCH_STACK

Previous thread: [GIT PULL][PATCH 0/12] IOMMU fixes for 2.6.34-rc3 by Joerg Roedel on Wednesday, April 7, 2010 - 5:46 am. (8 messages)

Next thread: [PATCH] btusb: Raw mode and ACL/SCO data by Kim B. Heino on Wednesday, April 7, 2010 - 5:53 am. (2 messages)
From: Stephane Eranian
Date: Wednesday, April 7, 2010 - 5:45 am

This patch exposes the branch trace buffer to users for sampling.
	There are measurements where it is very useful to couple the
	instruction address with some path information, e.g, basic
	block profiling.

	On recent Intel processors, the branch stack is implemented using
	the LBR registers. LBR was already used to fixup PEBS. This
	patch still allows PEBS fixups with LBR and also exposes LBR
	to applications.

	There is a new PERF_SAMPLE_BRANCH_STACK sample type. It creates
	a sample in the buffer which has the following layout:

	   { u64 nr;
	      { u64 from, to, flags } lbr[nr]; } && PERF_SAMPLE_BRANCH_STACK
 	   };

	Refer to include/linux/perf_event.h to figure out the layout ordering
	information.

	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.

	Signed-off-by: Stephane Eranian <eranian@google.com>

--
 arch/x86/kernel/cpu/perf_event_intel.c    |   13 +++++++++++++
 arch/x86/kernel/cpu/perf_event_intel_ds.c |    5 +++++
 include/linux/perf_event.h                |    8 +++++++-
 kernel/perf_event.c                       |   25 +++++++++++++++++++++++++
 4 files changed, 50 insertions(+), 1 deletion(-)

diff --git a/arch/x86/kernel/cpu/perf_event_intel.c b/arch/x86/kernel/cpu/perf_event_intel.c
index f168b40..6b8aa7d 100644
--- a/arch/x86/kernel/cpu/perf_event_intel.c
+++ b/arch/x86/kernel/cpu/perf_event_intel.c
@@ -562,8 +562,13 @@ static void intel_pmu_disable_event(struct perf_event *event)
 
 	x86_pmu_disable_event(event);
 
+	/*
+	 * PEBS implies LBR
+	 */
 	if (unlikely(event->attr.precise))
 		intel_pmu_pebs_disable(event);
+	else if (unlikely(event->attr.sample_type & PERF_SAMPLE_BRANCH_STACK))
+		intel_pmu_lbr_disable(event);
 }
 
 static void intel_pmu_enable_fixed(struct ...
From: Peter Zijlstra
Date: Wednesday, April 7, 2010 - 6:15 am

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.

--

From: Stephane Eranian
Date: Wednesday, April 7, 2010 - 9:48 am

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.
--

From: Peter Zijlstra
Date: Wednesday, April 7, 2010 - 9:54 am

Because I couldn't come up with a sensible use case.

--

Previous thread: [GIT PULL][PATCH 0/12] IOMMU fixes for 2.6.34-rc3 by Joerg Roedel on Wednesday, April 7, 2010 - 5:46 am. (8 messages)

Next thread: [PATCH] btusb: Raw mode and ACL/SCO data by Kim B. Heino on Wednesday, April 7, 2010 - 5:53 am. (2 messages)