Stephane Eranian | 7 Apr 14:45 2010
Picon

[PATCH] perf_events: add PERF_SAMPLE_BRANCH_STACK

	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 <at> google.com>

--
(Continue reading)

Peter Zijlstra | 7 Apr 15:15 2010

Re: [PATCH] perf_events: add PERF_SAMPLE_BRANCH_STACK

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.

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
Stephane Eranian | 7 Apr 18:48 2010
Picon

Re: [PATCH] perf_events: add PERF_SAMPLE_BRANCH_STACK

On Wed, Apr 7, 2010 at 3:15 PM, Peter Zijlstra <peterz <at> 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
(Continue reading)

Peter Zijlstra | 7 Apr 18:54 2010

Re: [PATCH] perf_events: add PERF_SAMPLE_BRANCH_STACK

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.

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
Stephane Eranian | 8 Apr 22:45 2010
Picon

[PATCH] perf_events: fix bogus warn_on(_once) in perf_prepare_sample()

	There is a warn_on_once() check for PERF_SAMPLE_RAW which trips
	when using PEBS on both Core and Nehalem. Core PEBS sample size is 144
	bytes and 176 bytes for Nehalem. Both are multiples of 8, but the size
	field is encoded as int, thus the total is never a multiple of 8 which
	trips the check. I think the size should have been u64, but now it is
	too late to change given it is ABI.

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

diff --git a/kernel/perf_event.c b/kernel/perf_event.c
index 8143e77..fffeb95 100644
--- a/kernel/perf_event.c
+++ b/kernel/perf_event.c
 <at>  <at>  -3311,7 +3311,6  <at>  <at>  void perf_prepare_sample(struct perf_event_header *header,
 		else
 			size += sizeof(u32);

-		WARN_ON_ONCE(size & (sizeof(u64)-1));
 		header->size += size;
 	}

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
Peter Zijlstra | 8 Apr 22:55 2010

Re: [PATCH] perf_events: fix bogus warn_on(_once) in perf_prepare_sample()

On Thu, 2010-04-08 at 22:45 +0200, Stephane Eranian wrote:
> 	There is a warn_on_once() check for PERF_SAMPLE_RAW which trips
> 	when using PEBS on both Core and Nehalem. Core PEBS sample size is 144
> 	bytes and 176 bytes for Nehalem. Both are multiples of 8, but the size
> 	field is encoded as int, thus the total is never a multiple of 8 which
> 	trips the check. I think the size should have been u64, but now it is
> 	too late to change given it is ABI.

PEBS hasn't seen -linus yet, so we can fix that.

There's various things that do indeed rely on the perf buffer to always
be u64 aligned, so this warning isn't bogus at all.

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
Peter Zijlstra | 8 Apr 23:03 2010

Re: [PATCH] perf_events: fix bogus warn_on(_once) in perf_prepare_sample()

On Thu, 2010-04-08 at 22:55 +0200, Peter Zijlstra wrote:
> On Thu, 2010-04-08 at 22:45 +0200, Stephane Eranian wrote:
> > 	There is a warn_on_once() check for PERF_SAMPLE_RAW which trips
> > 	when using PEBS on both Core and Nehalem. Core PEBS sample size is 144
> > 	bytes and 176 bytes for Nehalem. Both are multiples of 8, but the size
> > 	field is encoded as int, thus the total is never a multiple of 8 which
> > 	trips the check. I think the size should have been u64, but now it is
> > 	too late to change given it is ABI.
> 
> PEBS hasn't seen -linus yet, so we can fix that.
> 
> There's various things that do indeed rely on the perf buffer to always
> be u64 aligned, so this warning isn't bogus at all.

On the subject of PEBS, we need to change the ABI before it does hit
-linus, I've got something like the below,. but I'm not quite sure of
it.

We could keep the PERF_RECORD_MISC_EXACT bit and allow non-fixed up IPs
in PERF_SAMPLE_EVENT_IP fields, that way we can avoid having to add both
IP and EVENT_IP to samples.

---
Subject: perf: Change the PEBS interface
From: Peter Zijlstra <a.p.zijlstra <at> chello.nl>
Date: Tue Mar 30 13:35:58 CEST 2010

This patch changes the PEBS interface from perf_event_attr::precise
and PERF_RECORD_MISC_EXACT to perf_event_attr::precise and
PERF_SAMPLE_EVENT_IP.
(Continue reading)

Stephane Eranian | 8 Apr 23:08 2010
Picon

Re: [PATCH] perf_events: fix bogus warn_on(_once) in perf_prepare_sample()

On Thu, Apr 8, 2010 at 10:55 PM, Peter Zijlstra <peterz <at> infradead.org> wrote:
> On Thu, 2010-04-08 at 22:45 +0200, Stephane Eranian wrote:
>>       There is a warn_on_once() check for PERF_SAMPLE_RAW which trips
>>       when using PEBS on both Core and Nehalem. Core PEBS sample size is 144
>>       bytes and 176 bytes for Nehalem. Both are multiples of 8, but the size
>>       field is encoded as int, thus the total is never a multiple of 8 which
>>       trips the check. I think the size should have been u64, but now it is
>>       too late to change given it is ABI.
>
> PEBS hasn't seen -linus yet, so we can fix that.
>
Are you suggesting you add some padding the PEBS raw sample you
return as PERF_SAMPLE_RAW? Then you need to define what RAW
actually means? Seems here, it would mean more than what the
HW returns.

> There's various things that do indeed rely on the perf buffer to always
> be u64 aligned, so this warning isn't bogus at all.
>
I assume this has to do with the wrap-around detection.

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
perfmon2-devel mailing list
perfmon2-devel <at> lists.sourceforge.net
(Continue reading)

Peter Zijlstra | 8 Apr 23:11 2010

Re: [PATCH] perf_events: fix bogus warn_on(_once) in perf_prepare_sample()

On Thu, 2010-04-08 at 23:08 +0200, Stephane Eranian wrote:
> 
> Are you suggesting you add some padding the PEBS raw sample you
> return as PERF_SAMPLE_RAW? Then you need to define what RAW
> actually means? Seems here, it would mean more than what the
> HW returns. 

Well, RAW doesn't mean anything much at all, its really a fugly pass
some crap around thing.

So yeah, adding padding seems just fine.

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
Peter Zijlstra | 8 Apr 23:12 2010

Re: [PATCH] perf_events: fix bogus warn_on(_once) in perf_prepare_sample()

On Thu, 2010-04-08 at 23:08 +0200, Stephane Eranian wrote:
> 
> > There's various things that do indeed rely on the perf buffer to always
> > be u64 aligned, so this warning isn't bogus at all.
> >
> I assume this has to do with the wrap-around detection.

Nah, mostly dealing with architectures that don't do well with unaligned
accesses.

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev

Gmane