Thread (9 messages) 9 messages, 4 authors, 2012-03-27

Re: [PATCH] perf: Add a new sort order: SORT_INCLUSIVE (v4)

From: Peter Zijlstra <peterz@infradead.org>
Date: 2012-03-27 19:38:38
Also in: lkml

On Tue, 2012-03-27 at 11:09 -0700, Arun Sharma wrote:
On 3/24/12 7:14 PM, Frederic Weisbecker wrote:
quoted
quoted
The other problem in branch stacks/LBR is that they're
sampled branches. Just because I got a sample with:

a ->  b
b ->  c

doesn't necessarily mean that the callchain was a ->  b ->  c.
Not sure what you mean. If you have a ->  b, b ->  c in single
LBR sample it means you got a ->  b ->  c.
I was going by Stephane's commit message here:

http://article.gmane.org/gmane.linux.kernel/1236999

 > Statistical sampling of taken branch should not be confused
 > for branch tracing. Not all branches are necessarily captured

Stephane, could you please explain if the 16 filtered branches in LBR 
are guaranteed to be from a given callchain to the leaf function? My 
understanding is that it's not.

callchain1: a -> b -> d -> e (sample a->b)
callchain2: a -> c -> b -> f (sample b->f)

on PMU interrupt can we end up with:

b -> f <- top of stack
a -> b
...

even though a -> b -> f can never happen in the actual program flow?
Right, so the LBR is a queue not a stack. A program like:

foo() {
	bar1();
	bar2();
}

will, using the lbr, look like: foo->bar1->bar2 (if you filter returns),
or foo->bar1->foo+x->bar2 if you include returns.

A callchain is a pure stack, a return pops the top most entry, the above
program can only give 3 possible callchains:

a) foo
b) foo, bar1
c) foo, bar2

Furthermore, the LBR is about any branch, callchains are about function
calls.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help