From: Jiri Olsa <olsajiri@gmail.com>
To: Sun Jian <sun.jian.kdev@gmail.com>
Cc: Andrii Nakryiko <andrii@kernel.org>,
Shuah Khan <shuah@kernel.org>,
Eduard Zingerman <eddyz87@gmail.com>,
Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
bpf@vger.kernel.org, linux-kselftest@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 2/2] selftests/bpf: bpf_cookie: make perf_event subtest trigger reliably
Date: Mon, 2 Mar 2026 11:02:54 +0100 [thread overview]
Message-ID: <aaVgTiHlc4rXvzKJ@krava> (raw)
In-Reply-To: <20260228074555.122950-3-sun.jian.kdev@gmail.com>
On Sat, Feb 28, 2026 at 03:45:55PM +0800, Sun Jian wrote:
> The perf_event subtest relies on SW_CPU_CLOCK sampling to trigger the BPF
> program, but the current CPU burn loop can be too short on slower systems
> and may fail to generate any overflow sample. This leaves pe_res unchanged
> and makes the test flaky.
>
> Make burn_cpu() take a loop count and use a longer burn only for the
> perf_event subtest. Also scope perf_event_open() to the current task to
> avoid wasting samples on unrelated activity.
>
> Signed-off-by: Sun Jian <sun.jian.kdev@gmail.com>
>
> ---
> Changes in v2:
>
> Move the perf_event_open() argument change here from patch 1/2.
>
> v1: <https://lore.kernel.org/lkml/20260227164037.84110-1-sun.jian.kdev@gmail.com/>
> ---
> .../selftests/bpf/prog_tests/bpf_cookie.c | 19 +++++++++++--------
> 1 file changed, 11 insertions(+), 8 deletions(-)
>
> diff --git a/tools/testing/selftests/bpf/prog_tests/bpf_cookie.c b/tools/testing/selftests/bpf/prog_tests/bpf_cookie.c
> index b7643a5bf7ad..35adc3f6d443 100644
> --- a/tools/testing/selftests/bpf/prog_tests/bpf_cookie.c
> +++ b/tools/testing/selftests/bpf/prog_tests/bpf_cookie.c
> @@ -6,6 +6,7 @@
> #include <sys/syscall.h>
> #include <sys/mman.h>
> #include <unistd.h>
> +#include <linux/compiler.h>
> #include <test_progs.h>
> #include <network_helpers.h>
> #include <bpf/btf.h>
> @@ -431,11 +432,12 @@ static void tp_subtest(struct test_bpf_cookie *skel)
> bpf_link__destroy(link3);
> }
>
> -static void burn_cpu(void)
> +static void burn_cpu(long loops)
nit, there's another burn_cpu in prog_tests/perf_link.c,
we could add it to trace_helpers.c or test_progs.c
> {
> - volatile int j = 0;
> + long j = 0;
> cpu_set_t cpu_set;
> - int i, err;
> + long i;
> + int err;
>
> /* generate some branches on cpu 0 */
> CPU_ZERO(&cpu_set);
> @@ -443,9 +445,10 @@ static void burn_cpu(void)
> err = pthread_setaffinity_np(pthread_self(), sizeof(cpu_set), &cpu_set);
> ASSERT_OK(err, "set_thread_affinity");
>
> - /* spin the loop for a while (random high number) */
> - for (i = 0; i < 1000000; ++i)
> + for (i = 0; i < loops; ++i) {
> ++j;
> + barrier();
what's the rationale for barrier call in here,
together with the volatile change above?
thanks,
jirka
> + }
> }
>
> static void pe_subtest(struct test_bpf_cookie *skel)
> @@ -461,7 +464,7 @@ static void pe_subtest(struct test_bpf_cookie *skel)
> attr.type = PERF_TYPE_SOFTWARE;
> attr.config = PERF_COUNT_SW_CPU_CLOCK;
> attr.sample_period = 100000;
> - pfd = syscall(__NR_perf_event_open, &attr, -1, 0, -1, PERF_FLAG_FD_CLOEXEC);
> + pfd = syscall(__NR_perf_event_open, &attr, 0, -1, -1, PERF_FLAG_FD_CLOEXEC);
> if (!ASSERT_GE(pfd, 0, "perf_fd"))
> goto cleanup;
>
> @@ -470,7 +473,7 @@ static void pe_subtest(struct test_bpf_cookie *skel)
> if (!ASSERT_OK_PTR(link, "link1"))
> goto cleanup;
>
> - burn_cpu(); /* trigger BPF prog */
> + burn_cpu(100000000L); /* trigger BPF prog */
>
> ASSERT_EQ(skel->bss->pe_res, 0x100000, "pe_res1");
>
> @@ -489,7 +492,7 @@ static void pe_subtest(struct test_bpf_cookie *skel)
> if (!ASSERT_OK_PTR(link, "link2"))
> goto cleanup;
>
> - burn_cpu(); /* trigger BPF prog */
> + burn_cpu(100000000L); /* trigger BPF prog */
>
> ASSERT_EQ(skel->bss->pe_res, 0x200000, "pe_res2");
>
> --
> 2.43.0
>
>
next prev parent reply other threads:[~2026-03-02 10:02 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-28 7:45 [PATCH v2 0/2] selftests/bpf: fix bpf_cookie failures Sun Jian
2026-02-28 7:45 ` [PATCH v2 1/2] selftests/bpf: bpf_cookie: skip kprobe_multi tests without bpf_testmod Sun Jian
2026-03-02 10:02 ` Jiri Olsa
2026-02-28 7:45 ` [PATCH v2 2/2] selftests/bpf: bpf_cookie: make perf_event subtest trigger reliably Sun Jian
2026-03-02 10:02 ` Jiri Olsa [this message]
2026-03-03 2:15 ` sun jian
2026-03-03 21:32 ` Jiri Olsa
2026-03-05 23:10 ` [PATCH v2 0/2] selftests/bpf: fix bpf_cookie failures patchwork-bot+netdevbpf
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=aaVgTiHlc4rXvzKJ@krava \
--to=olsajiri@gmail.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=eddyz87@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=shuah@kernel.org \
--cc=sun.jian.kdev@gmail.com \
/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.