What does 'Samples' mean in perf output? - profile

Question

I used linux perf to profile my program and I can not understand the result.
10.5% 2 fun ..........
|
|- 80% - ABC
| call_ABC
-- 20% - DEF
call_DEF
The above example means that 'fun' has two samples and contributes 10.5% overheads,
and 80% of them is called from ABC, 20% from DEF. Am I right?
Now we have only two samples, then how does 'perf' calculate the fraction of ABC and DEF?
Why aren't they 50%? dose 'perf' use additional information?

Answer 1

The above example means that 'fun' has two samples and contributes 10.5% overheads,
Yes, this part of perf report -g -n shows that 2 of 19 samples (2 is 10.5% of 19) was in the foo function itself. 17 other samples were sampled in the other function.
I just reproduced your code with recent gcc (-static -O3 -fno-inline -fno-omit-frame-pointer -g) and perf (perf record -e cycles:u -c 500000 -g ./test12968422 for low resolution samples or -c 5000 for high resolution). Now perf has bit different weight rules, but idea should be same. When there is only 2 samples for the program and both are in the foo, call-graph (perf report -n -g callee) is 50 for every of call_DEF/_ABC (no additional information). This program actually had 86% of runtime in foo, 61% of them when called from ABC, 25% of 86 when called from DEF:
100% 2 fun
- fun
+ 50% call_DEF
+ 50% call_ABC
What are the kind of additional information perf may use to reconstruct more information? I think it can be either self weight of call_DEF and call_ABC; or it can be frequency of "call_ABC->foo" and "call_DEF->foo" parts of callchain in the all sample call stacks.
With perf from linux kernel versions 4.4 / 4.10 I can't reproduce your situation. I added different amount of self work in the call_ABC and call_DEF. Both of them just calls foo for fixed amount of work. Now I have 19 samples of -e cycles:u -c 54000 -g, 13 for call_ABC, 2 for call_DEF, 2 for fun (and 2 in some random functions):
Children Self Samples Symbol
74% 68% 13 [.] call_ABC
16% 10.5% 2 [.] call_DEF
10.5% 10.5% 2 [.] fun
- fun
+ 5.26% call_ABC
+ 5.26% call_DEF
So, try newer version of perf, not from epoch of 3.2 Linux kernels.
First source of fun only work, inequal shares when called from ABC and from DEF:
#define g 100000
int a[2+g];
void fill_a(){
a[0]=0;
for(int f=0;f<g;f++)
a[f+1]=f;
}
int fun(int b)
{
while(a[b])
b=a[b];
return b;
}
int call_ABC(int b)
{
int d = b;
b = fun(d);
return d-b;
}
int call_DEF(int b)
{
int e = b;
b = fun(e);
return e+b;
}
int main()
{
int c,d;
fill_a();
c=call_ABC(100000);
c=call_DEF(45000);
return c+d;
}
Second source of inequal work in ABC and DEF with equal small work in fun:
#define g 100000
int a[2+g];
void fill_a(){
a[0]=0;
for(int f=0;f<g;f++)
a[f+1]=f;
}
int fun(int b)
{
while(a[b])
b=a[b];
return b;
}
int call_ABC(int b)
{
int d = b;
while(a[d])
d=a[d];
b = fun(5000);
return d-b;
}
int call_DEF(int b)
{
int e = b;
while(a[e])
e=a[e];
b = fun(5000);
return e+b;
}
int main()
{
int c,d;
fill_a();
c=call_ABC(100000);
c=call_DEF(20000);
return c+d;
}