linux-kernel - Re: [PATCHv2 00/45] perf stat: Add scripting support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 30 Sep 2015 23:34:07 +0200
From:	Jiri Olsa <jolsa@...hat.com>
To:	"Liang, Kan" <kan.liang@...el.com>
Cc:	Jiri Olsa <jolsa@...nel.org>,
	Arnaldo Carvalho de Melo <acme@...nel.org>,
	Andi Kleen <andi@...stfloor.org>,
	Ulrich Drepper <drepper@...il.com>,
	Will Deacon <will.deacon@....com>,
	Stephane Eranian <eranian@...gle.com>,
	Don Zickus <dzickus@...hat.com>,
	lkml <linux-kernel@...r.kernel.org>,
	David Ahern <dsahern@...il.com>,
	Ingo Molnar <mingo@...nel.org>,
	Namhyung Kim <namhyung@...nel.org>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>
Subject: Re: [PATCHv2 00/45] perf stat: Add scripting support

On Wed, Sep 30, 2015 at 09:09:39PM +0000, Liang, Kan wrote:

SNIP

> > Examples:
> > 
> > - To record data for command stat workload:
> > 
> >   $ perf stat record kill
> >   ...
> > 
> >    Performance counter stats for 'kill':
> > 
> >             0.372007      task-clock (msec)         #    0.613 CPUs utilized
> >                    3      context-switches          #    0.008 M/sec
> >                    0      cpu-migrations            #    0.000 K/sec
> >                   62      page-faults               #    0.167 M/sec
> >            1,129,973      cycles                    #    3.038 GHz
> >      <not supported>      stalled-cycles-frontend
> >      <not supported>      stalled-cycles-backend
> >              813,313      instructions              #    0.72  insns per cycle
> >              166,161      branches                  #  446.661 M/sec
> >                8,747      branch-misses             #    5.26% of all branches
> > 
> >          0.000607287 seconds time elapsed
> > 
> 
> The default file for perf stat record is perf.data.
> It's easy to be mix up with the data file from perf record.
> How about using perf.data.stat to instead?

hum, I'm inclined to keep using the perf.data as default
of whatever comes out of the perf.. and do the 'perf report'
proxy based on the data you described in the next comment

SNIP

> > - To store system-wide period stat data:
> > 
> >   $ perf stat -e cycles:u,instructions:u -a -I 1000 record
> >   #           time             counts unit events
> >        1.000265471        462,311,482      cycles:u                   (100.00%)
> >        1.000265471        590,037,440      instructions:u
> >        2.000483453        722,532,336      cycles:u                   (100.00%)
> >        2.000483453        848,678,197      instructions:u
> >        3.000759876         75,990,880      cycles:u                   (100.00%)
> >        3.000759876         86,187,813      instructions:u
> >   ^C     3.213960893         85,329,533      cycles:u                   (100.00%)
> >        3.213960893        135,954,296      instructions:u
> > 
> > - To report perf stat data:
> >
> 
> Could we support perf report as well?
> If I run perf report with the data file, there are some warnings.
> We know the data file is from perf stat or perf record, so it should
> be not hard to handle the warnings.

well perf report wants to display sampling data which are
not present.. probabbly complaining about sample_type I guess

I think 'perf report' could check on perf.data and if it
detects stat data proxy the handling to the perf stat report

but not sure how to handle both commands options differencies ATM

> Also it's better that all the new record type (CPU/THREAD_MAP,
> STAT_CONFIG, STAT and etc) can be dumped by perf report -D.
> It shows unhandled now.

right, I'll those

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