perf tools: software regression in d0a0a511493d269514fcbd852481cdca32c95350

["Adrián Herrera Arcila" <adrian.herrera@arm.com>]

Hello all,

The regression affects the perf command "stat" used with the option "-D 
msecs, --delay msecs". The change was introduced in v5.18 and was 
backported up to v5.15.33 of 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git. In 
v5.18, the behaviour of the affected option is described in 
tools/perf/Documentation/perf-stat.txt as follows:

"After starting the program, wait msecs before measuring (-1: start with 
events disabled). This is useful to filter out the startup phase of the 
program, which is often very different."

The program is expected to start without delay. The observed behaviour 
in v5.18 does not correspond, as demonstrated by the following experiments:

time perf stat --delay 2000 --quiet sleep 2
v5.18 output:
Events disabled
Events enabled

real    0m4.065s
user    0m0.019s
sys    0m0.028s
v5.17 output:
Events disabled
Events enabled

real    0m2.028s
user    0m0.001s
sys    0m0.008s

perf stat --delay 2000 --quiet echo "marking"
v5.18 output:
Events disabled
Events enabled
marking
v5.17 output:
Events disabled
marking
Events enabled

I think there are two behaviours that are valuable to maintain to enable 
two uses: (1) if no delay is specified, the program should start after 
counters are enabled, to prevent the unexpected behaviour that Thomas 
fixed with this change; (2) if delay is specified, the program should 
start before the delay is engaged.

Two possible solutions are: (1) though conditionals; if delay > 0, start 
the workload, then call enable_counters, which will usleep for the 
delay; if no delay, then behaviour as it is in v5.18; (2) replace 
blocking usleep with asynchronous callback, if that exists in Linux, 
that enables counters after the delay.

Any suggestions from more experienced Linux developers on which solution 
to pursue will be appreciated.

Kind regards,
Adrián.