From: kajoljain <kjain@linux.ibm.com>
To: Jin Yao <yao.jin@linux.intel.com>,
acme@kernel.org, jolsa@kernel.org, peterz@infradead.org,
mingo@redhat.com, alexander.shishkin@linux.intel.com
Cc: Linux-kernel@vger.kernel.org, ak@linux.intel.com,
kan.liang@intel.com, yao.jin@intel.com
Subject: Re: [PATCH v2] perf stat: Improve runtime stat for interval mode
Date: Tue, 21 Apr 2020 12:40:23 +0530 [thread overview]
Message-ID: <3d966653-bba1-f2ee-b77f-8d892f7976da@linux.ibm.com> (raw)
In-Reply-To: <20200420145417.6864-1-yao.jin@linux.intel.com>
On 4/20/20 8:24 PM, Jin Yao wrote:
> For interval mode, the metric is printed after # if it exists. But
> it's not calculated by the counts generated in this interval. See
> following examples,
>
> root@kbl-ppc:~# perf stat -M CPI -I1000 --interval-count 2
> # time counts unit events
> 1.000422803 764,809 inst_retired.any # 2.9 CPI
> 1.000422803 2,234,932 cycles
> 2.001464585 1,960,061 inst_retired.any # 1.6 CPI
> 2.001464585 4,022,591 cycles
>
> The second CPI should not be 1.6 (4,022,591/1,960,061 is 2.1)
>
> root@kbl-ppc:~# perf stat -e cycles,instructions -I1000 --interval-count 2
> # time counts unit events
> 1.000429493 2,869,311 cycles
> 1.000429493 816,875 instructions # 0.28 insn per cycle
> 2.001516426 9,260,973 cycles
> 2.001516426 5,250,634 instructions # 0.87 insn per cycle
>
> The second 'insn per cycle' should not be 0.87 (5,250,634/9,260,973 is 0.57).
>
> The current code uses a global variable rt_stat for tracking and
> updating the std dev of runtime stat. Unlike the counts, rt_stat is
> not reset for interval. While the counts are reset for interval.
>
> perf_stat_process_counter()
> {
> if (config->interval)
> init_stats(ps->res_stats);
> }
>
> So for interval, the rt_stat should be reset either.
>
> This patch resets rt_stat before read_counters, so the runtime
> stat is only calculated by the counts generated in this interval.
>
> With this patch,
>
> root@kbl-ppc:~# perf stat -M CPI -I1000 --interval-count 2
> # time counts unit events
> 1.000420924 2,408,818 inst_retired.any # 2.1 CPI
> 1.000420924 5,010,111 cycles
> 2.001448579 2,798,407 inst_retired.any # 1.6 CPI
> 2.001448579 4,599,861 cycles
>
> root@kbl-ppc:~# perf stat -e cycles,instructions -I1000 --interval-count 2
> # time counts unit events
> 1.000428555 2,769,714 cycles
> 1.000428555 774,462 instructions # 0.28 insn per cycle
> 2.001471562 3,595,904 cycles
> 2.001471562 1,243,703 instructions # 0.35 insn per cycle
>
> Now the second 'insn per cycle' and CPI are calculated by the counts
> generated in this interval.
>
> v2:
> ---
> Use just existing perf_stat__reset_shadow_per_stat(&rt_stat).
> We don't need to define new function perf_stat__reset_rt_stat.
>
> Signed-off-by: Jin Yao <yao.jin@linux.intel.com>
> ---
> tools/perf/Documentation/perf-stat.txt | 2 ++
> tools/perf/builtin-stat.c | 1 +
> 2 files changed, 3 insertions(+)
>
> diff --git a/tools/perf/Documentation/perf-stat.txt b/tools/perf/Documentation/perf-stat.txt
> index 4d56586b2fb9..3fb5028aef08 100644
> --- a/tools/perf/Documentation/perf-stat.txt
> +++ b/tools/perf/Documentation/perf-stat.txt
> @@ -176,6 +176,8 @@ Print count deltas every N milliseconds (minimum: 1ms)
> The overhead percentage could be high in some cases, for instance with small, sub 100ms intervals. Use with caution.
> example: 'perf stat -I 1000 -e cycles -a sleep 5'
>
> +If the metric exists, it is calculated by the counts generated in this interval and the metric is printed after #.
> +
> --interval-count times::
> Print count deltas for fixed number of times.
> This option should be used together with "-I" option.
> diff --git a/tools/perf/builtin-stat.c b/tools/perf/builtin-stat.c
> index 9207b6c45475..3f050d85c277 100644
> --- a/tools/perf/builtin-stat.c
> +++ b/tools/perf/builtin-stat.c
> @@ -359,6 +359,7 @@ static void process_interval(void)
> clock_gettime(CLOCK_MONOTONIC, &ts);
> diff_timespec(&rs, &ts, &ref_time);
>
> + perf_stat__reset_shadow_per_stat(&rt_stat);
Tested-By: Kajol Jain <kjain@linux.ibm.com>
Thanks,
Kajol
> read_counters(&rs);
>
> if (STAT_RECORD) {
>
next prev parent reply other threads:[~2020-04-21 7:10 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-20 14:54 [PATCH v2] perf stat: Improve runtime stat for interval mode Jin Yao
2020-04-21 7:10 ` kajoljain [this message]
2020-04-21 13:53 ` Arnaldo Carvalho de Melo
2020-04-22 0:53 ` Jin, Yao
2020-04-22 1:08 ` Arnaldo Melo
2020-04-23 13:44 ` Arnaldo Carvalho de Melo
2020-04-22 7:22 ` Jiri Olsa
2020-05-08 13:05 ` [tip: perf/core] " tip-bot2 for Jin Yao
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3d966653-bba1-f2ee-b77f-8d892f7976da@linux.ibm.com \
--to=kjain@linux.ibm.com \
--cc=Linux-kernel@vger.kernel.org \
--cc=acme@kernel.org \
--cc=ak@linux.intel.com \
--cc=alexander.shishkin@linux.intel.com \
--cc=jolsa@kernel.org \
--cc=kan.liang@intel.com \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=yao.jin@intel.com \
--cc=yao.jin@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.