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 for Android: free password hash cracker in your pocket

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

Message-ID: <20150924081912.GE2024@krava.redhat.com>
Date:	Thu, 24 Sep 2015 10:19:12 +0200
From:	Jiri Olsa <jolsa@...hat.com>
To:	kan.liang@...el.com
Cc:	acme@...nel.org, jolsa@...nel.org, a.p.zijlstra@...llo.nl,
	mingo@...hat.com, namhyung@...nel.org, ak@...ux.intel.com,
	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

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

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 ;-)

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