mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: James Clark <james.clark@linaro.org>
To: Ian Rogers <irogers@google.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@redhat.com>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	Namhyung Kim <namhyung@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	Jiri Olsa <jolsa@kernel.org>,
	Adrian Hunter <adrian.hunter@intel.com>,
	Jakub Brnak <jbrnak@redhat.com>, Leo Yan <leo.yan@arm.com>,
	Arnaldo Carvalho de Melo <acme@redhat.com>,
	linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v4 4/4] perf test: Don't starve per-process tests with system-wide events
Date: Tue, 10 Nov 2026 12:30:14 +0000	[thread overview]
Message-ID: <2c48c893-9ab5-4883-bafb-a2580b76c4c1@linaro.org> (raw)
In-Reply-To: <CAP-5=fX-AuoMOL+yPXw2FsdcC5Xg7qkb-Q038U3BeB+P+Rf_Yg@mail.gmail.com>



On 09/11/2026 17:47, Ian Rogers wrote:
> On Mon, Nov 9, 2026 at 5:48 AM James Clark <james.clark@linaro.org> wrote:
>>
>> Some tests intermittently fail when run in parallel, for example "Check
>> branch stack sampling" fails with no branches recorded at all.
>>
>> The default event is cycles:P which there may only be 1 or 2 HW counters
>> for on Intel because it's precise. System wide or per-core precise
>> events hog the HW counter leaving other per-process tests with no
>> samples. Rather than make all the tests that use default record commands
>> run serially, just make the system wide ones use a software event which
>> has the greatest possible compatibility. They don't need precise
>> sampling or HW counters anyway. The per-process tests can be left alone
>> as their events/processes never run concurrently on any one core.
>>
>> The LBR filter is another resource shared by all events on a CPU, and
>> the system-wide LBR test uses different filters to the per-process
>> branch stack test, so mark the LBR test as exclusive.
> 
> Thanks for deflaking the tests! Making the LBR test exclusive is
> pragmatic; however, it also feels like a shame since recording LBR
> data in parallel should be something we expect users to do.
> 
> For PMUs that can have a single user we have logic which prints
> conflicting users in dump_perf_event_processes:
> https://web.git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools-next.git/tree/tools/perf/util/evsel.c?h=perf-tools-next#n4519
> 
> I wonder if, when we get zero counts or no samples we could perform a
> similar analysis and report conflicting users—though this would
> inherently be racy. If we had that, maybe we could just repeat the LBR
> tests until there are no conflicting users and not need the exclusive
> tag.
> 

Yeah re-running the test for certain failures would probably work well. 
But at the same time if we know certain resources are limited and we're 
running per-CPU and per-thread events at the same time in a way that we 
know won't multiplex at all, maybe it would be better to re-write the 
parallel tests to only use per-thread events.

Even when multiplexing works there can be issues. For example another 
flake I looked at was in the metrics tests. Some of them test that the 
ratios don't exceed 100% for example, but multiplexing can break this 
assumption if all the counters in the metric are only in a weak group 
and they aren't always scheduled at the same time. There was a lot to 
unpick in that one so I dropped it. But it's a similar problem.

I think some of the kernel PMU scheduling and sharing decisions expect 
that any root user running things per-CPU is "well behaved" or 
understands the impact to other users that their events might have. And 
we're probably not doing that enough in the tests to honor that.

Another example for this is with Arm BRBE. There are multiple counters 
on the PMU, so you can have multiple events, but there's only one BRBE 
and one filter, and the branch history is limited. The driver takes the 
union of filters for all the PMU events running and then post processes 
the branch buffer for each user to not leak anything from the other 
event's filter. But imagine that one test gives a certain restricted 
filter and expects to completely fill up the branch buffer, and that 
exact full buffer is required for the test. When another root event runs 
in parallel on the same core, the filter can be widened and the buffer 
gets blown up with other branches that weren't interesting to the other 
test, and are filtered out by the driver anyway making it fail.

> Anyway, doing all of that is a bigger project.
> 

Yep. and maybe something to keep in mind for any new tests or when doing 
further flake investigations.

> Reviewed-by: Ian Rogers <irogers@google.com>
> 

Thanks!

> Thanks,
> Ian
> 
>> This fixes the "Check branch stack sampling" test and other flakes when
>> a system-wide record from another test runs at the same time, for
>> example:
>>
>>    $ sudo perf record -a -o /dev/null -- sleep 30 &
>>    $ sudo perf test -vvv "Check branch stack sampling"
>>    ...
>>    Testing user branch stack sampling
>>    ERROR: Branches missing ^brstack_bench\+[^ ]*/brstack_foo\+[^ ]*/IND_CALL/.*$
>>    ...
>>    Testing user branch stack sampling [Failed]
>>    ...
>>    Testing branch stack filtering permutation (call,CALL|SYSCALL)
>>    Testing branch stack filtering [Failed empty script output]
>>    ...
>>    ---- end(-1) ----
>>    138: Check branch stack sampling : FAILED!
>>
>> Signed-off-by: James Clark <james.clark@linaro.org>
>> ---
>>   tools/perf/tests/shell/record.sh          | 6 +++---
>>   tools/perf/tests/shell/record_lbr.sh      | 2 +-
>>   tools/perf/tests/shell/record_sideband.sh | 4 ++--
>>   3 files changed, 6 insertions(+), 6 deletions(-)
>>
>> diff --git a/tools/perf/tests/shell/record.sh b/tools/perf/tests/shell/record.sh
>> index 01dc3e22fa73..e4789e2bcf43 100755
>> --- a/tools/perf/tests/shell/record.sh
>> +++ b/tools/perf/tests/shell/record.sh
>> @@ -388,7 +388,7 @@ test_system_wide() {
>>     echo "Basic --system-wide mode test"
>>     local ret=0
>>     perf_record_with_retry "${perfdata}" "check_system_wide" "perf test -w thloop" \
>> -    -aB --synth=no || ret=$?
>> +    -aB --synth=no -e cpu-clock || ret=$?
>>     if [ $ret -eq 2 ]; then
>>       echo "System-wide record [Skipped not supported]"
>>       return
>> @@ -471,7 +471,7 @@ test_cgroup() {
>>     echo "Cgroup sampling test"
>>     local ret=0
>>     perf_record_with_retry "${perfdata}" "check_cgroup" "perf test -w thloop" \
>> -    -aB --synth=cgroup --all-cgroups || ret=$?
>> +    -aB --synth=cgroup --all-cgroups -e cpu-clock || ret=$?
>>     if [ $ret -eq 2 ]; then
>>       echo "Cgroup sampling [Skipped not supported]"
>>       return
>> @@ -491,7 +491,7 @@ test_uid() {
>>     echo "Uid sampling test"
>>     local ret=0
>>     perf_record_with_retry "${perfdata}" "check_uid" "perf test -w thloop" \
>> -    -aB --synth=no --uid "$(id -u)" || ret=$?
>> +    -aB --synth=no --uid "$(id -u)" -e cpu-clock || ret=$?
>>     if [ $ret -eq 2 ]; then
>>       local logfile="${PERF_RECORD_LOGS[${#PERF_RECORD_LOGS[@]}-1]}"
>>       if grep -q -E "libbpf.*EPERM|Access to performance monitoring" "$logfile" || \
>> diff --git a/tools/perf/tests/shell/record_lbr.sh b/tools/perf/tests/shell/record_lbr.sh
>> index 8d51afeb437b..6b6af59db871 100755
>> --- a/tools/perf/tests/shell/record_lbr.sh
>> +++ b/tools/perf/tests/shell/record_lbr.sh
>> @@ -1,6 +1,6 @@
>>   #!/bin/bash
>>   # SPDX-License-Identifier: GPL-2.0
>> -# perf record LBR tests
>> +# perf record LBR tests (exclusive)
>>
>>   set -e
>>
>> diff --git a/tools/perf/tests/shell/record_sideband.sh b/tools/perf/tests/shell/record_sideband.sh
>> index 2182551873be..f16889e3fa9a 100755
>> --- a/tools/perf/tests/shell/record_sideband.sh
>> +++ b/tools/perf/tests/shell/record_sideband.sh
>> @@ -22,7 +22,7 @@ trap trap_cleanup EXIT TERM INT
>>
>>   can_cpu_wide()
>>   {
>> -    if ! perf record -o ${perfdata} -BN --no-bpf-event -C $1 true > /dev/null 2>&1
>> +    if ! perf record -o ${perfdata} -BN --no-bpf-event -e cpu-clock -C $1 true > /dev/null 2>&1
>>       then
>>           echo "record sideband test [Skipped cannot record cpu$1]"
>>           err=2
>> @@ -39,7 +39,7 @@ test_system_wide_tracking()
>>       can_cpu_wide 1 || return 0
>>
>>       # Record on CPU 0 a task running on CPU 1
>> -    perf record -BN --no-bpf-event -o ${perfdata} -C 0 -- taskset --cpu-list 1 true
>> +    perf record -BN --no-bpf-event -e cpu-clock -o ${perfdata} -C 0 -- taskset --cpu-list 1 true
>>
>>       # Should get MMAP events from CPU 1
>>       mmap_cnt=`perf script -i ${perfdata} --show-mmap-events -C 1 2>/dev/null | grep MMAP | wc -l`
>>
>> --
>> 2.43.0
>>


  reply	other threads:[~2026-11-10 12:30 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-09 13:48 [PATCH v4 0/4] perf tools: LLVM dwarf and flaky test fixes James Clark
2026-11-09 13:48 ` [PATCH v4 1/4] perf libdw: Find the CU by iterating all CUs when aranges are missing James Clark
2026-11-09 13:48 ` [PATCH v4 2/4] perf dwarf-aux: Support DW_OP_addrx locations for global variables James Clark
2026-11-09 13:48 ` [PATCH v4 3/4] perf test probe_vfs_getname: Fix missing debuginfo detection James Clark
2026-11-09 13:48 ` [PATCH v4 4/4] perf test: Don't starve per-process tests with system-wide events James Clark
2026-11-09 17:47   ` Ian Rogers
2026-11-10 12:30     ` James Clark [this message]
2026-11-10 16:49       ` Ian Rogers
2026-11-09 18:20 ` [PATCH v4 0/4] perf tools: LLVM dwarf and flaky test fixes Ian Rogers

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=2c48c893-9ab5-4883-bafb-a2580b76c4c1@linaro.org \
    --to=james.clark@linaro.org \
    --cc=acme@kernel.org \
    --cc=acme@redhat.com \
    --cc=adrian.hunter@intel.com \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=irogers@google.com \
    --cc=jbrnak@redhat.com \
    --cc=jolsa@kernel.org \
    --cc=leo.yan@arm.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®