Re: [PATCH v6 13/18] perf: add support for taken branch sampling toperf report

From: Ingo Molnar
Date: Wed Feb 22 2012 - 06:15:32 EST



* Stephane Eranian <eranian@xxxxxxxxxx> wrote:

> From: Roberto Agostino Vitillo <ravitillo@xxxxxxx>
>
> This patch adds support for taken branch sampling, i.e, the
> PERF_SAMPLE_BRANCH_STACK feature to perf report. In other
> words, to display histograms based on taken branches rather
> than executed instructions addresses.
>
> The new option is called -b and it takes no argument. To
> generate meaningful output, the perf.data must have been
> obtained using perf record -b xxx ... where xxx is a branch
> filter option.
>
> The output shows symbols, modules, sorted by 'who branches
> where' the most often. The percentages reported in the first
> column refer to the total number of branches captured and
> not the usual number of samples.
>
> Here is a quick example.
> Here branchy is simple test program which looks as follows:
>
> void f2(void)
> {}
> void f3(void)
> {}
> void f1(unsigned long n)
> {
> if (n & 1UL)
> f2();
> else
> f3();
> }
> int main(void)
> {
> unsigned long i;
>
> for (i=0; i < N; i++)
> f1(i);
> return 0;
> }
>
> Here is the output captured on Nehalem, if we are
> only interested in user level function calls.
>
> $ perf record -b any_call,u -e cycles:u branchy
>
> $ perf report -b --sort=symbol
> 52.34% [.] main [.] f1
> 24.04% [.] f1 [.] f3
> 23.60% [.] f1 [.] f2
> 0.01% [k] _IO_new_file_xsputn [k] _IO_file_overflow
> 0.01% [k] _IO_vfprintf_internal [k] _IO_new_file_xsputn
> 0.01% [k] _IO_vfprintf_internal [k] strchrnul
> 0.01% [k] __printf [k] _IO_vfprintf_internal
> 0.01% [k] main [k] __printf

Ok, nice feature.

One detail needs to be fixed though, if someone does:

perf record -b ...

then 'perf report' should *default* to the above branch stack
output style, without having to specify -b again.

Having --branch/--no-branch present in perf report is fine if
someone wants to force either direction, but the default
absolutely must be picked up from the perf.data and should be
the obvious behavior.

Other than that it looks good to me, so if this detail is fixed
(can be a delta patch on top of the existing series) and there's
no problems with it I can pick it up for v3.4.

Thanks,

Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/