lkml.org 
[lkml]   [2013]   [Dec]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 1/3] perf tools: Record total sampling time

* Namhyung Kim <namhyung@kernel.org> wrote:

> 2013-12-02 (월), 13:57 +0100, Ingo Molnar:
> > So basically, in the end I think it should be possible to have the
> > following behavior:
> >
> > perf record -a -e cycles sleep 1
> >
> > perf report stat # Reports as if we ran: 'perf stat -a -e cycles sleep 1'
> > perf report # Reports the usual histogram
> >
> > perf report --stat # Reports the perf stat output and the histogram
> >
> > or so.
>
> I don't think we need both of 'perf report stat' and 'perf report
> --stat'. At least it looks somewhat confusing to users IMHO.

Okay. Maybe the --stat option would be the more logical choice,
because '--' options can be added arbitrarily, while it would be weird
to add multiple subcommand options.

So basically there would be two options:

--show-stat [--no-show-stat]
--show-histogram [--no-show-histogram]

Today --show-histogram is the only one enabled by default.

Running:

perf report --no-show-histogram --show-stat

would give perf-stat output.

This --show-* pattern could be used in the future, for example to
express debug output:

perf report --show-debug

Or to show other details that are off by default.

'perf report --show' should perhaps list all --show options that are
available currently.

Maybe the syntax should be similar to the sort option?

What's your preference?

> For perf report stat usage, I think there's not much thing we can do
> for a single event - the most case. We can simple show total count
> and elapsed (or sampled time) for the event, but it's already in the
> header with this patch.
>
> # Samples: 4K of event 'cycles'
> # Event count (approx.): 4087481688
> # Total sampling time : 1.001260 (sec)

That's what I mean, instead of 'this patch' we should utilize perf
stat output mode. That will solve your particular feature request
here, plus gives us much more: it gives perf stat integration into
report.

> If an user really want to see perf stat-like output (without the
> usual histogram) for a recorded session, it'd be better to have
> 'perf record --stat' do the job (like git diff --stat) IMHO.

Why? Showing the result is a reporting feature really. Firstly we
record everything, then we 'analyze', looking at various details of
data.

Getting perf stat output could be used to get a first, rough, high
level overview.

> > i.e. a perf.data file would by default always carry enough information
> > to enable the extraction of the 'perf stat' data.
> >
> > At that point visualizing it is purely report-time logic, it does not
> > need any record-time options.
> >
> > This would work for multi-event sampling as well, if we do:
> >
> > perf record -a -e cycles -e branches sleep 1
> >
> > then 'perf report stat' would output the same as:
> >
> > $ perf stat -e cycles -e branches -a sleep 1
> >
> > Performance counter stats for 'system wide':
> >
> > 34,174,518 cycles [100.00%]
> > 3,155,677 branches
> >
> > 1.000802852 seconds time elapsed
> >
>
> Yeah, it'd be good to have same output both for perf stat and perf
> report --stat (or stat if you want). But I don't think it's
> possible to determine multiplexed counter values like perf stat does
> unless we use PERF_SAMPLE_READ for recoding.

That's my point: is there any reason why we shouldn't turn on
PERF_SAMPLE_READ for these events, and read them at the beginning and
at the end of a sampling session?

( some people might even want periodic samples emitted inbetween, to
be able to see a time flow representation of samples, but that's for
the future. )

> > Another neat feature this kind of workflo enables is the integration
> > of --repeat to perf record, so something like:
> >
> > perf record --repeat 3 -a -e cycles -e branches sleep 1
> >
> > would save 3 samples after each other, and would allow extraction of
> > the statistical stability of the measurement, and 'perf report stat'
> > would print the same result as a raw perf stat run would:
> >
> > $ perf stat --repeat 3 -e cycles -e branches -e instructions -a sleep 1
> >
> > Performance counter stats for 'system wide' (3 runs):
> >
> > 28,975,150,642 cycles ( +- 0.43% ) [100.00%]
> > 10,740,235,371 branches ( +- 0.47% ) [100.00%]
> > 44,535,464,754 instructions # 1.54 insns per cycle ( +- 0.47% )
> >
> > 1.005718027 seconds time elapsed ( +- 0.43% )
>
> Yeah, but it can be used only for a new forked workload.

Well, it can be used for anything that perf record can do today,
except maybe the Ctrl-C method of measurement, right?

> > Or something like that. At that point we share reporting between
> > perf stat and perf report, no special ad-hoc options are needed to
> > just measure and report timestamps, it would all be a 'natural'
> > side effect of having perf stat.
> >
> > What do you think?
>
> I think it'd be better if we can share code as much as possible.
> And it'd much better if we can forget about the difference in
> options. :)

Agreed - see the --show-<xyz> pattern I suggested above.

It could be different as well, sort-key alike:

--show +stat,-hist,+debug

Thanks,

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

\
 
 \ /
  Last update: 2013-12-02 17:41    [W:0.177 / U:0.080 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site