From: Arnaldo Carvalho de Melo <acme@kernel.org>
To: Namhyung Kim <namhyung@kernel.org>, Jiri Olsa <jolsa@kernel.org>,
Changbin Du <changbin.du@huawei.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@redhat.com>,
Mark Rutland <mark.rutland@arm.com>,
Ian Rogers <irogers@google.com>,
Alexander Shishkin <alexander.shishkin@linux.intel.com>,
linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org,
Hui Wang <hw.huiwang@huawei.com>
Subject: Re: [PATCH] perf: fix counting when initial delay configured
Date: Thu, 23 Feb 2023 10:45:13 -0300 [thread overview]
Message-ID: <Y/dt6QpsCj5AAUE/@kernel.org> (raw)
In-Reply-To: <20230223075800.1795777-1-changbin.du@huawei.com>
Em Thu, Feb 23, 2023 at 03:58:00PM +0800, Changbin Du escreveu:
> When creating counters with initial delay configured, the enable_on_exec
> field is not set. So we need to enable the counters later. The problem
> is, when a workload is specified the target__none() is still true. So
> we also need to check stat_config.initial_delay.
>
> Before this fix the event is not counted:
> $ ./perf stat -e instructions -D 100 sleep 2
> Events disabled
> Events enabled
>
> Performance counter stats for 'sleep 2':
>
> <not counted> instructions
>
> 1.901661124 seconds time elapsed
>
> 0.001602000 seconds user
> 0.000000000 seconds sys
>
> After fix it works:
> $ ./perf stat -e instructions -D 100 sleep 2
> Events disabled
> Events enabled
>
> Performance counter stats for 'sleep 2':
>
> 404,214 instructions
>
> 1.901743475 seconds time elapsed
>
> 0.001617000 seconds user
> 0.000000000 seconds sys
>
> Fixes: c587e77e100f ("perf stat: Do not delay the workload with --delay")
Yeap, even the comment states that we need to enable when initial_delay
is set :-)
I added the additional test output below.
Namhyung, can you please ack it?
- Arnaldo
Committer testing:
Before:
Lets use stress-ng so that we have lots of samples using a CPU stressor
and also intermingle the workload output with the messages about when
the events get enabled (i.e. later on in the workload):
$ perf stat -e instructions -D 100 stress-ng -c 32 -t 1
Events disabled
stress-ng: info: [38361] setting to a 1 second run per stressor
stress-ng: info: [38361] dispatching hogs: 32 cpu
Events enabled
stress-ng: info: [38361] successful run completed in 1.01s
Performance counter stats for 'stress-ng -c 32 -t 1':
<not counted> instructions:u
0.916479141 seconds time elapsed
30.868003000 seconds user
0.049851000 seconds sys
Some events weren't counted. Try disabling the NMI watchdog:
echo 0 > /proc/sys/kernel/nmi_watchdog
perf stat ...
echo 1 > /proc/sys/kernel/nmi_watchdog
$
After the fix:
$ perf stat -e instructions -D 100 stress-ng -c 32 -t 1
Events disabled
stress-ng: info: [40429] setting to a 1 second run per stressor
stress-ng: info: [40429] dispatching hogs: 32 cpu
Events enabled
stress-ng: info: [40429] successful run completed in 1.01s
Performance counter stats for 'stress-ng -c 32 -t 1':
154117865145 instructions:u
0.920827644 seconds time elapsed
30.864753000 seconds user
0.073862000 seconds sys
$
> Signed-off-by: Changbin Du <changbin.du@huawei.com>
> ---
> tools/perf/builtin-stat.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/tools/perf/builtin-stat.c b/tools/perf/builtin-stat.c
> index 9f3e4b257516..c71d85577de6 100644
> --- a/tools/perf/builtin-stat.c
> +++ b/tools/perf/builtin-stat.c
> @@ -544,7 +544,7 @@ static int enable_counters(void)
> * - we don't have tracee (attaching to task or cpu)
> * - we have initial delay configured
> */
> - if (!target__none(&target)) {
> + if (!target__none(&target) || stat_config.initial_delay) {
> if (!all_counters_use_bpf)
> evlist__enable(evsel_list);
> }
> --
> 2.25.1
>
--
- Arnaldo
next prev parent reply other threads:[~2023-02-23 13:46 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-23 7:58 [PATCH] perf: fix counting when initial delay configured Changbin Du
2023-02-23 13:45 ` Arnaldo Carvalho de Melo [this message]
2023-02-23 22:48 ` Namhyung Kim
2023-02-24 7:25 ` Changbin Du
2023-02-24 23:36 ` Namhyung Kim
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=Y/dt6QpsCj5AAUE/@kernel.org \
--to=acme@kernel.org \
--cc=alexander.shishkin@linux.intel.com \
--cc=changbin.du@huawei.com \
--cc=hw.huiwang@huawei.com \
--cc=irogers@google.com \
--cc=jolsa@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=mingo@redhat.com \
--cc=namhyung@kernel.org \
--cc=peterz@infradead.org \
/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.