Messages in this thread | | | Date | Mon, 1 Aug 2022 19:45:58 +0800 | From | Leo Yan <> | Subject | Re: [PATCH 2/2] perf stat: fix unexpected delay behaviour |
| |
On Fri, Jul 29, 2022 at 04:12:44PM +0000, Adrián Herrera Arcila wrote: > The described --delay behaviour is to delay the enablement of events, but > not the execution of the command, if one is passed, which is incorrectly > the current behaviour. > > This patch decouples the enablement from the delay, and enables events > before or after launching the workload dependent on the options passed > by the user. This code structure is inspired by that in perf-record, and > tries to be consistent with it. > > Link: https://lore.kernel.org/linux-perf-users/7BFD066E-B0A8-49D4-B635-379328F0CF4C@fb.com > Fixes: d0a0a511493d ("perf stat: Fix forked applications enablement of counters") > Signed-off-by: Adrián Herrera Arcila <adrian.herrera@arm.com>
bpf_counter() is not enabled for delay in this patch, but I think this is purposed to keep the same behaviour with before. I would leave it to Song for a call.
The patch LGTM and I tested with commands:
$ time ./perf stat --delay 2000 --quiet sleep 2 Events disabled Events enabled
real 0m2.039s user 0m0.007s sys 0m0.016s
$ ./perf stat --delay 2000 --quiet echo "marking" Events disabled marking Events enabled
Reviewed-by: Leo Yan <leo.yan@linaro.org> Tested-by: Leo Yan <leo.yan@linaro.org>
P.s. I took a bit time to get clear how 'perf stat' set enable_on_exec flag, which is set in the function create_perf_stat_counter(), so this can enable PMU event for the case when delay is zero, and this can avoid losing PMU tracing for workload.
| |