On Wed, 2026-06-10 at 15:04 +0200, Valentin Schneider wrote: > Osnoise already implictly accounts IPIs via its IRQ tracking,
Does it? It seems that IPIs bypass the kernel/irq subsystem on some arches (including x86, but not ARM). It would be nice to solve this properly by adding generic ipi entry/exit tracing (similar to what ARM already has). > however it > can be interesting to distiguish between the two: undesired IPIs usually > imply a software configuration issue (e.g. wrong/incomplete CPU isolation) > whereas undesired (non-IPI) IRQs usually imply a hardware configuration > issue. > > Signed-off-by: Valentin Schneider <[email protected]> > --- > Note that this is modifying the osnoise:osnoise_entry Ftrace entry; I know > trace events are sort of supposed to be stable, but I'm not sure about > ftrace entries. I think old rtla will be OK with this since it looks up fields by name rather than assuming a fixed layout. > Alternatively I can have this be purely supported in userspace osnoise by > hooking into the IPI events and counting IPIs separately from the osnoise > events. One benefit I could see of doing this in kernel osnoise would be if you could atomically correlate the count with the particular noise interval, but this patch doesn't do that. > +static void ipi_emission(struct osnoise_variables *osn_var, unsigned int > dst_cpu) > +{ > + if (!osn_var->sampling) > + return; > + > + osn_var->ipi.count++; > +} > + > +static void trace_ipi_send_cpu_callback(void *data, unsigned int cpu, > + unsigned long callsite, void *callback) > +{ > + struct osnoise_variables *osn_var; > + > + osn_var = per_cpu_ptr(&per_cpu_osnoise_var, cpu); > + ipi_emission(osn_var, cpu); > +} > + > +static void trace_ipi_send_cpumask_callback(void *data, const struct cpumask > *cpumask, > + unsigned long callsite, void > *callback) > +{ > + struct osnoise_variables *osn_var; > + int cpu; > + > + for_each_cpu_and(cpu, cpumask, &osnoise_cpumask) { > + osn_var = per_cpu_ptr(&per_cpu_osnoise_var, cpu); > + ipi_emission(osn_var, cpu); > + } > +} Isn't this racy to do from a different CPU? Both in terms of the counter, and the timing of the increment relative to when the IPI is actually received. Not necessarily a huge deal if you only care about zero versus bignum, but still. At least worth a comment, if we go with this approach. -Crystal
