From: Jiri Olsa <olsajiri@gmail.com>
To: sun jian <sun.jian.kdev@gmail.com>
Cc: Jiri Olsa <olsajiri@gmail.com>,
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: Tue, 3 Mar 2026 22:32:23 +0100 [thread overview]
Message-ID: <aadTZ8r5XAn4-pOt@krava> (raw)
In-Reply-To: <CABFUUZGAK-kD75QAc8acfoGvPVj+EuaFNLT7rcPcWP7SOnpKqw@mail.gmail.com>
On Tue, Mar 03, 2026 at 10:15:26AM +0800, sun jian wrote:
> On Mon, Mar 2, 2026 at 6:02 PM Jiri Olsa <olsajiri@gmail.com> wrote:
> >
> > 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
> > > -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
> >
>
> happy to refactor into a shared helper if maintainers prefer, but I keep it
> local to minimize the diff.
>
> > > {
> > > - 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?
> >
>
> The burn_cpu() loop is only meant to consume CPU time to reliably trigger the
> SW_CPU_CLOCK perf_event overflow. With an side-effect-free loop, the
> compiler may optimize the loop away or significantly shrink it under -O2.
>
> The old version relied on volatile to prevent the loop from being optimized, but
> checkpatch warns against it. Using barrier() achieves the same goal — keep the
> loop intact as a CPU-burn — while making the intent more explicit.
ok, would be great to have this in the changelog, other than that:
Acked-by: Jiri Olsa <jolsa@kernel.org>
thanks,
jirka
next prev parent reply other threads:[~2026-03-03 21:32 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
2026-03-03 2:15 ` sun jian
2026-03-03 21:32 ` Jiri Olsa [this message]
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=aadTZ8r5XAn4-pOt@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.