On Mon, Mar 2, 2026 at 6:02 PM Jiri Olsa <[email protected]> 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
