On Tue, Mar 03, 2026 at 10:15:26AM +0800, sun jian wrote: > 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.
ok, would be great to have this in the changelog, other than that: Acked-by: Jiri Olsa <[email protected]> thanks, jirka
