On Mon, Mar 2, 2026 at 3:59 AM Emil Tsalapatis <[email protected]> wrote: > > On Fri Feb 27, 2026 at 11:40 AM EST, Sun Jian wrote: > > The perf_event subtest relies on SW_CPU_CLOCK sampling to trigger the BPF > > Signed-off-by: Sun Jian <[email protected]> > > Reviewed-by: Emil Tsalapatis <[email protected]> > > Nit below, but change makes sense. > Hi Emil, Thanks a lot for the review and the Reviewed-by! > > --- > > -static void burn_cpu(void) > > +static void burn_cpu(long loops) > > { > > - volatile int j = 0; > > + long j = 0; > > Nit: AFAICT most of these changes are unnecessary, you could just bump > the cycle count to 100M and add the barrier. Moving everything to longs > and factoring out the loop count is unnecessary. > Good point about keeping the diff small. In v2 I dropped the volatile and added a barrier().
v2: https://lore.kernel.org/lkml/[email protected]/ I kept the loop-count parameter mainly to keep the "long burn to trigger perf_event" intent explicit at the call site, and to avoid hard-coding a large constant in the helper if it gets reused later. Thanks again, Sun Jian
