Re: [PATCH v2 2/2] selftests/bpf: bpf_cookie: make perf_event subtest trigger reliably

sun jian
2026-03-03T02:15:39Z

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.

Thanks,
Sun Jian