linux-perf-users.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Veronika Molnarova <vmolnaro@redhat.com>
To: Namhyung Kim <namhyung@kernel.org>
Cc: linux-perf-users@vger.kernel.org, acme@kernel.org,
	acme@redhat.com, mpetlan@redhat.com
Subject: Re: [PATCH] perf test stat_bpf_counter.sh: Remove comparison of separate runs
Date: Thu, 6 Jun 2024 15:09:43 +0200	[thread overview]
Message-ID: <6a33f2f6-fd69-4e90-8cd5-a73d393c20a1@redhat.com> (raw)
In-Reply-To: <Zl-x8uob6NT3HlfT@google.com>



On 6/5/24 02:31, Namhyung Kim wrote:
> On Tue, Jun 04, 2024 at 05:31:11PM +0200, vmolnaro@redhat.com wrote:
>> From: Veronika Molnarova <vmolnaro@redhat.com>
>>
>> The test has been failing for some time when two separate runs of
>> perf benchmarks are recorded and the counts of the samples are compared,
>> while once the recording was done with option --bpf-counters and once
>> without it. It is expected that the count of the samples should within
>> a certain range, firstly the difference should have been within 10%,
>> which was then later raised to 20%. However, the test case keeps failing
>> on certain architectures as recording the same benchmark can provide
>> completely different counts samples based on the current load of the
>> system.
>>
>> Sampling two separate runs on intel-eaglestream-spr-13 of "perf stat
>> --no-big-num -e cycles -- perf bench sched messaging -g 1 -l 100 -t":
>>
>>  Performance counter stats for 'perf bench sched messaging -g 1 -l 100 -t':
>>
>>          396782898      cycles
>>
>>        0.010051983 seconds time elapsed
>>
>>        0.008664000 seconds user
>>        0.097058000 seconds sys
>>
>>  Performance counter stats for 'perf bench sched messaging -g 1 -l 100 -t':
>>
>>         1431133032      cycles
>>
>>        0.021803714 seconds time elapsed
>>
>>        0.023377000 seconds user
>>        0.349918000 seconds sys
>>
>> , which is ranging from 400mil to 1400mil samples.
>>
>> From the testing point of view, it does not make sense to compare two
>> separate runs against each other when the conditions may change
>> significantly. Remove the comparison of two separate runs and check only
>> whether the stating works as expected for the --bpf-counters option. Compare
>> the samples count only when the samples are recorded simultaneously
>> ensuring the same conditions.
> 
> Hmm.. but having a test which checks if the output is sane can be
> useful.  If it's a problem of dynamic changes in cpu cycles, maybe
> we can use 'instructions' event instead (probably with :u) to get
> more stable values?
> 
> Thanks,
> Namhyung
> 

Well but isn't it better to check the sanity of the output if the counters are recorded
for a load with the same conditions as has been added in patch d9bd1d4
"perf test bpf-counters: Add test for BPF event modifier" utilizing the event modifiers: 
perf stat --no-big-num -e cycles/name=base_cycles/,cycles/name=bpf_cycles/b -- $workload?
Comparing two separate runs is more based on the stability of the workload than the
bpf-counters option, which then causes the issue of defining the threshold of what values
are still within the sane range.

But you are right that another possible fix for this issue is to change the workload or the
event to get some more stable values, which could be comparable.

Thanks,
Veronika

>>
>> Signed-off-by: Veronika Molnarova <vmolnaro@redhat.com>
>> ---
>>  tools/perf/tests/shell/stat_bpf_counters.sh | 13 ++++++-------
>>  1 file changed, 6 insertions(+), 7 deletions(-)
>>
>> diff --git a/tools/perf/tests/shell/stat_bpf_counters.sh b/tools/perf/tests/shell/stat_bpf_counters.sh
>> index 61f8149d854e..873b576836c6 100755
>> --- a/tools/perf/tests/shell/stat_bpf_counters.sh
>> +++ b/tools/perf/tests/shell/stat_bpf_counters.sh
>> @@ -6,19 +6,19 @@ set -e
>>  
>>  workload="perf bench sched messaging -g 1 -l 100 -t"
>>  
>> -# check whether $2 is within +/- 20% of $1
>> +# check whether $2 is within +/- 10% of $1
>>  compare_number()
>>  {
>>  	first_num=$1
>>  	second_num=$2
>>  
>> -	# upper bound is first_num * 120%
>> -	upper=$(expr $first_num + $first_num / 5 )
>> -	# lower bound is first_num * 80%
>> -	lower=$(expr $first_num - $first_num / 5 )
>> +	# upper bound is first_num * 110%
>> +	upper=$(expr $first_num + $first_num / 10 )
>> +	# lower bound is first_num * 90%
>> +	lower=$(expr $first_num - $first_num / 10 )
>>  
>>  	if [ $second_num -gt $upper ] || [ $second_num -lt $lower ]; then
>> -		echo "The difference between $first_num and $second_num are greater than 20%."
>> +		echo "The difference between $first_num and $second_num are greater than 10%."
>>  		exit 1
>>  	fi
>>  }
>> @@ -44,7 +44,6 @@ test_bpf_counters()
>>  	base_cycles=$(perf stat --no-big-num -e cycles -- $workload 2>&1 | awk '/cycles/ {print $1}')
>>  	bpf_cycles=$(perf stat --no-big-num --bpf-counters -e cycles -- $workload  2>&1 | awk '/cycles/ {print $1}')
>>  	check_counts $base_cycles $bpf_cycles
>> -	compare_number $base_cycles $bpf_cycles
>>  	echo "[Success]"
>>  }
>>  
>> -- 
>> 2.43.0
>>
> 


  reply	other threads:[~2024-06-06 13:09 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-04 15:31 [PATCH] perf test stat_bpf_counter.sh: Remove comparison of separate runs vmolnaro
2024-06-05  0:31 ` Namhyung Kim
2024-06-06 13:09   ` Veronika Molnarova [this message]
2024-06-07 18:38     ` Namhyung Kim
2024-06-13 14:20   ` Michael Petlan
2024-06-16  3:56     ` 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=6a33f2f6-fd69-4e90-8cd5-a73d393c20a1@redhat.com \
    --to=vmolnaro@redhat.com \
    --cc=acme@kernel.org \
    --cc=acme@redhat.com \
    --cc=linux-perf-users@vger.kernel.org \
    --cc=mpetlan@redhat.com \
    --cc=namhyung@kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).