linux-kernel - RE: [PATCH RFC 00/10] counter read during perf sampling

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]
Message-ID: <37D7C6CF3E00A74B8858931C1DB2F07701941815@shsmsx102.ccr.corp.intel.com>
Date:	Thu, 24 Sep 2015 19:47:40 +0000
From:	"Liang, Kan" <kan.liang@...el.com>
To:	Jiri Olsa <jolsa@...hat.com>
CC:	"acme@...nel.org" <acme@...nel.org>,
	"jolsa@...nel.org" <jolsa@...nel.org>,
	"a.p.zijlstra@...llo.nl" <a.p.zijlstra@...llo.nl>,
	"mingo@...hat.com" <mingo@...hat.com>,
	"namhyung@...nel.org" <namhyung@...nel.org>,
	"ak@...ux.intel.com" <ak@...ux.intel.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH RFC 00/10] counter read during perf sampling



> On Tue, Sep 22, 2015 at 10:13:33AM -0400, kan.liang@...el.com wrote:
> > From: Kan Liang <kan.liang@...el.com>
> >
> > The patch series intends to read counter statistics with fixed
> > frequency during sampling. The instant benefit is that we can read
> > memory bandwidth from uncore event during cpu PMU event is
> sampling.
> >
> > Introduce 'C' event/group modifier. The event with this modifier will
> > do counting not sampling. If a group with this modifier, only group
> > leader do sampling. The counter statistics will be wrote in new RECORD
> > type PERF_RECORD_COUNTER_READ and stored in perf.data.
> > So perf report can present the counter statistics data accordingly.
> >
> > There may be an alternative way to get counter statistics during
> > sampling by running perf record and perf stat together by script.
> > But the script way have various issue and complex to parses the
> > output.
> 
> just a thought, but isn't the way then llow to store the data from perf
> stat? ;-) and be able to merge perf.data-s from perf record and stat
> afterwards

Yes, the way to store the data from perf stat is better than pure script
way. I guess your patch "perf stat record" can do that, right?

If so, how should we run perf record and stat in parallel? By scripts or
modify perf record/stat? 

Also, we need an option in perf report to merge the perf.data-s. Right?

> 
> >
> > Example:
> >
> >  $perf record -e 'cycles,uncore_imc_1/cas_count_read/C'
> >   --counter-read-interval 10 -a ./tchain_edit  [ perf record: Woken up
> > 438 times to write data ]  [ perf record: Captured and wrote 1.232 MB
> > perf.data (17901 samples) ]
> 
> but if we go this way I think we should keep/allow all the options perf stat

Do you mean something like "perf record stat"?
That's not the way I designed. I don't want to run perf record and perf stat
together in one command.

I just want to do similar thing like what sample read did. Sample read can read
counters on each sample. While the counter read can read counters in a fix
frequency (set by --counter-read-interval). So it's an extension of perf record.
It applies all possible options of perf record, like -C -a -g... 
I introduce a new option --counter-read-interval is because that there is no
 interval options in perf record.

> 
> something like:
>   $ perf record -e cycles stat -e 'uncore_imc_1/cas_count_read/' -I 10000 -
> a ./tchain_edit
> 
> with all the stat option we allow -c -F ...
> and reusing existing stat code
> 
> >  $perf report -D
> >
> >  0x3cae0 [0x28]: PERF_RECORD_COUNTER_READ:
> uncore_imc_1/cas_count_read/C
> >                 CPU 0: val 1205 ena 2046148 run 2046148
> >
> >  0x3cb08 [0x28]: PERF_RECORD_COUNTER_READ:
> uncore_imc_1/cas_count_read/C
> >                 CPU 18: val 1315 ena 2001918 run 2001918
> >
> >  0x3dba0 [0x28]: PERF_RECORD_COUNTER_READ:
> uncore_imc_1/cas_count_read/C
> >                 CPU 0: val 1588 ena 12191520 run 12191520
> >
> >  0x3dbc8 [0x28]: PERF_RECORD_COUNTER_READ:
> uncore_imc_1/cas_count_read/C
> >                 CPU 18: val 1686 ena 12162202 run 12162202
> >
> >  $perf report --stdio --socket-filter 0
> >
> >  # To display the perf.data header info, please use --header/--header-
> only options.
> >  #
> >  #
> >  # Total Lost Samples: 0
> >  #
> >  # Samples: 17K of event 'cycles'
> >  # Event count (approx.): 10119095556
> >  # Processor Socket: 0
> >  #
> >  # Overhead  Command       Shared Object        Symbol
> >  # ........  ............  ...................  ..................................
> >  #
> >     97.68%  tchain_edit   tchain_edit          [.] f3
> >      0.07%  tchain_edit   tchain_edit          [.] f2
> >      0.04%  swapper       [kernel.vmlinux]     [k] run_timer_softirq
> >      0.04%  swapper       [kernel.vmlinux]     [k] find_busiest_group
> >
> >  # Samples: 0  of event 'uncore_imc_1/cas_count_read/C'
> >  # Event count (approx.): 0
> >  # Processor Socket: 0
> >  # uncore_imc_1/cas_count_read/C: 35937
> 
> I think we'll need special output/display for non sampling events,
> something like extra window in TUI and distinguished output in stdio, the
> above is hacked sampling output ;-)

I think it depends on what way we finally use.

If we use the way which merging perf.data from perf stat and record, I think
we need special output for the data from perf stat in TUI/stdio.

But if we use the way counter read (:C), I think the best place to show the
counter read results is the header/title (just like the patch did). Because the
results are the aggregate counts during the whole sampling process.
Something like,
# Event count: 35937 of event 'uncore_imc_1/cas_count_read/C'

Thanks,
Kan

--
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/