Re: [PATCH v3 10/11] perf tools report: Implement browsing of individual samples
> > +--samples=N:: > > + Save N individual samples for each histogram entry to show context in > > perf > > + report tui browser. > > maybe we could set some default value (50?) 50 wouldn't fit on the screen. I turned it off by default intentionally because it will increase the memory consumption of perf report quite a bit. It might be possible to set some small default though, but right now I guess whoever wants it can enable it. -Andi
Re: [PATCH v3 10/11] perf tools report: Implement browsing of individual samples
On Thu, Feb 28, 2019 at 10:35:49AM -0800, Andi Kleen wrote:
SNIP
> diff --git a/tools/perf/util/hist.c b/tools/perf/util/hist.c
> index 6040eb49ea23..ba8a58f2cdd0 100644
> --- a/tools/perf/util/hist.c
> +++ b/tools/perf/util/hist.c
> @@ -593,6 +593,40 @@ static struct hist_entry *hists__findnew_entry(struct
> hists *hists,
> return he;
> }
>
> +static unsigned random_max(unsigned high)
> +{
> + unsigned thresh = -high % high;
> + for (;;) {
> + unsigned r = random();
> + if (r >= thresh)
> + return r % high;
> + }
> +}
> +
> +static void hists__res_sample(struct hist_entry *he, struct perf_sample
> *sample)
> +{
> + struct res_sample *r;
> + int j;
> +
> + if (!he->res_samples) {
> + he->res_samples = calloc(sizeof(struct res_sample),
> + symbol_conf.res_sample);
> + if (!he->res_samples)
> + return;
> + }
please allocate this in hist_entry__init
thanks,
jirka
Re: [PATCH v3 10/11] perf tools report: Implement browsing of individual samples
On Thu, Feb 28, 2019 at 10:35:49AM -0800, Andi Kleen wrote: > From: Andi Kleen > > Now report can show whole time periods with perf script, > but the user still has to find individual samples of interest > manually. > > It would be expensive and complicated to search for the > right samples in the whole perf file. Typically users > only need to look at a small number of samples for useful > analysis. > > Also the full scripts tend to show samples of all CPUs and all > threads mixed up, which can be very confusing on larger systems. > > Add a new --samples option to save a small random number of samples > per hist entry > > Use a reservoir sample technique to select a representatve > number of samples. > > Then allow browsing the samples using perf script > as part of the hist entry context menu. This automatically > adds the right filters, so only the thread or cpu of the sample > is displayed. Then we use less' search functionality > to directly jump the to the time stamp of the selected > sample. > > It uses different menus for assembler and source display. > Assembler needs xed installed and source needs debuginfo. > > Currently it only supports as many samples as fit on > the screen due to some limitations in the slang ui code. > > Signed-off-by: Andi Kleen > > --- > v2: > Free names on error path > Pass --inline and --show-*-event to child perf as needed. > --- > tools/perf/Documentation/perf-report.txt | 4 ++ > tools/perf/builtin-report.c | 2 + > tools/perf/ui/browsers/Build | 1 + > tools/perf/ui/browsers/hists.c | 47 ++ > tools/perf/ui/browsers/res_sample.c | 80 > tools/perf/ui/browsers/scripts.c | 2 +- > tools/perf/util/hist.c | 36 +++ > tools/perf/util/hist.h | 19 ++ > tools/perf/util/sort.h | 8 +++ > tools/perf/util/symbol.c | 1 + > tools/perf/util/symbol_conf.h| 1 + > 11 files changed, 200 insertions(+), 1 deletion(-) > create mode 100644 tools/perf/ui/browsers/res_sample.c > > diff --git a/tools/perf/Documentation/perf-report.txt > b/tools/perf/Documentation/perf-report.txt > index 546d87221ad8..f441baa794ce 100644 > --- a/tools/perf/Documentation/perf-report.txt > +++ b/tools/perf/Documentation/perf-report.txt > @@ -461,6 +461,10 @@ include::itrace.txt[] > --socket-filter:: > Only report the samples on the processor socket that match with this > filter > > +--samples=N:: > + Save N individual samples for each histogram entry to show context in > perf > + report tui browser. maybe we could set some default value (50?) jirka
Re: [PATCH v3 10/11] perf tools report: Implement browsing of individual samples
On Thu, Feb 28, 2019 at 10:35:49AM -0800, Andi Kleen wrote: > From: Andi Kleen > > Now report can show whole time periods with perf script, > but the user still has to find individual samples of interest > manually. > > It would be expensive and complicated to search for the > right samples in the whole perf file. Typically users > only need to look at a small number of samples for useful > analysis. > > Also the full scripts tend to show samples of all CPUs and all > threads mixed up, which can be very confusing on larger systems. > > Add a new --samples option to save a small random number of samples > per hist entry > > Use a reservoir sample technique to select a representatve > number of samples. > > Then allow browsing the samples using perf script > as part of the hist entry context menu. This automatically > adds the right filters, so only the thread or cpu of the sample > is displayed. Then we use less' search functionality > to directly jump the to the time stamp of the selected > sample. when I choose: 148156.305096328: CPU 0 tid 16402 ▒ I'm getting: sched-messaging 16402 [000] 148156.305096328: 886205 cycles:ppp: 93a001ad syscall_return_via_sysret+0xbc ([kernel.kallsyms]) sched-messaging 16402 [000] 148156.305344526: 887134 cycles:ppp: 933f8c7d avc_has_perm+0xcd ([kernel.kallsyms]) sched-messaging 16402 [000] 148156.305594286: 888614 cycles:ppp: 93208a02 stackleak_erase+0xa2 ([kernel.kallsyms]) sched-messaging 16402 [000] 148156.305843034: 888750 cycles:ppp: 93986d30 _raw_spin_lock+0x10 ([kernel.kallsyms]) sched-messaging 16402 [000] 148156.306091824: 889265 cycles:ppp: 932c623e __vfs_write+0xbe ([kernel.kallsyms]) sched-messaging 16402 [000] 148156.306340739: 889802 cycles:ppp: 937eaee4 skb_set_owner_w+0x54 ([kernel.kallsyms]) sched-messaging 16402 [000] 148156.306590950: 890449 cycles:ppp: 93291e33 __kmalloc_node_track_caller+0xc3 ([kernel.kallsyms]) sched-messaging 16402 [000] 148156.306840144: 890348 cycles:ppp: 932089a9 stackleak_erase+0x49 ([kernel.kallsyms]) sched-messaging 16402 [000] 148156.307089348: 890707 cycles:ppp: 932e60e6 __fget_light+0x46 ([kernel.kallsyms]) sched-messaging 16402 [000] 148156.307338691: 891063 cycles:ppp: 938ed2a3 unix_stream_sendmsg+0x213 ([kernel.kallsyms]) sched-messaging 16402 [001] 148156.323855201: 916081 cycles:ppp: 93208a05 stackleak_erase+0xa5 ([kernel.kallsyms]) sched-messaging 16402 [001] 148156.324104737: 916330 cycles:ppp: 93986d30 _raw_spin_lock+0x10 ([kernel.kallsyms]) sched-messaging 16402 [001] 148156.324354188: 916467 cycles:ppp: 9324192f kmalloc_slab+0x4f ([kernel.kallsyms]) systemd-journal 882 [005] 148156.373698788: PERF_RECORD_FORK(882:16422):(882:882) systemd-journal 882 [005] 148156.373718699: PERF_RECORD_FORK(882:16423):(882:882) journal-offline 16422 [002] 148156.373720344: PERF_RECORD_COMM: journal-offline:882/16422 journal-offline 16423 [005] 148156.373766480: PERF_RECORD_COMM: journal-offline:882/16423 journal-offline 16423 [005] 148156.385947319: PERF_RECORD_EXIT(882:16423):(882:16423) systemd-journal 882 [002] 148156.386052146: PERF_RECORD_FORK(882:16424):(882:882) journal-offline 16424 [001] 148156.386069865: PERF_RECORD_COMM: journal-offline:882/16424 journal-offline 16422 [002] 148156.386132447: PERF_RECORD_EXIT(882:16422):(882:16422) journal-offline 16424 [001] 148156.389171176: PERF_RECORD_EXIT(882:16424):(882:16424) systemd-journal 882 [002] 148156.389263406: PERF_RECORD_FORK(882:16425):(882:882) some other cpus and threads mixed in jirka
Re: [PATCH v3 10/11] perf tools report: Implement browsing of individual samples
On Thu, Feb 28, 2019 at 10:35:49AM -0800, Andi Kleen wrote: > From: Andi Kleen > > Now report can show whole time periods with perf script, > but the user still has to find individual samples of interest > manually. > > It would be expensive and complicated to search for the > right samples in the whole perf file. Typically users > only need to look at a small number of samples for useful > analysis. > > Also the full scripts tend to show samples of all CPUs and all > threads mixed up, which can be very confusing on larger systems. > > Add a new --samples option to save a small random number of samples > per hist entry > > Use a reservoir sample technique to select a representatve > number of samples. > > Then allow browsing the samples using perf script > as part of the hist entry context menu. This automatically > adds the right filters, so only the thread or cpu of the sample > is displayed. Then we use less' search functionality > to directly jump the to the time stamp of the selected > sample. I'm getting this error for workload sampling: File does not contain CPU events. Remove -C option to proceed. jirka
